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FOREWORD 


REA  Bulletin  66-10,  "Power  System  Communications:  Supervisory  Control 

and  Energy  Management  Systems,"  is  part  of  the  series  of  REA  bulletins 
dedicated  to  power  systems  communications  and  control  systems.  This 
publication  is  the  first  of  its  kind  to  specifically  deal  with  rural 
electric  cooperatives'  design  and  implementation  requirements  for 
supervisory  control  and  energy  management  systems.  The  subject  area 
of  this  bulletin  includes  control  functions,  operations,  design  con- 
siderations, hardware  and  software  requirements,  design  criteria, 
system  implementation,  and  costs. 

The  functional  presentation  of  the  material  in  this  bulletin  should  be 
of  significant  value  to  all  cooperative  engineers  and  consulting  firms 
and  particularly  helpful  to  engineers  beginning  their  careers  in  power 
systems  control  and  energy  management. 
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I . GENERAL 


A.  Introduction 


This  bulletin  provides  a planning  and  design  guide  for  electric 
system  borrower  energy  monitoring  and  control  systems.  The 
planning  and  engineering  procedures  are  based  on  the  classical 
systems  engineering  approach  which  has  proven  to  be  very 
effective  in  planning  large,  high  technology  projects. 

Four  basic  categories  of  real-time  control  systems  are  common- 
ly used  by  REA  electric  borrowers.  They  include: 

° Supervisory  Control  and  Data  Acquisition  (SCADA) 

° SCADA  with  Automatic  Generation  Control 

0 Energy  Management  Systems 

0 In-Plant  or  Direct  Digital  Control  Systems 

Supervisory  Control  and  Data  Acquisition  (SCADA)  systems  are 
intended  primarily  for  periodic  data  acquisition  from  sub- 
stations and  generating  stations  and  for  remote  control  of 
equipment  at  these  stations.  They  are  occasionally  expanded 
to  also  include  automatic  generation  control.  Other  functions 
common  to  SCADA  systems  include  alarm  generation,  log  and 
report  generation  and  electronic  tagging.  In  some  situations 
SCADA  systems  are  also  used  to  acquire,  store  and  selectively 
forward  data  from  a regional  control  center  to  a central 
system  control  center. 

Energy  Management  or  Energy  Control  Systems  are  an  outgrowth 
of  SCADA  systems  and  usually  include  most  SCADA  system 
functions  although  supervisory  control  is  occasionally 
omitted.  Energy  Management  and  Energy  Control  Systems  are 
characterized  by  incorporating  a broader  and  more  complex  set 
of  functions  than  is  found  in  the  typical  SCADA  system.  These 
functions  may  include  a wide  range  of  generation,  transmission 
and  system  security  applications  requiring  more  extensive  data 
acquisition  and  computing  facilities. 

In-plant  or  Direct  Digital  Control  (DDC)  systems  are  typified 
by  those  commonly  found  in  generating  stations  for  unit  mon- 
itoring, start-up,  shutdown,  and  for  unit  allocation.  Functions 
of  these  systems  vary  considerably  between  fossil  fuel,  nuclear 
and  hydro  generating  plants. 
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Many  system  configurations  are  possible  for  utility  monitoring 
and  control  systems.  The  configuration  best  suited  to  a 
specific  case  is  largely  dependent  on  the  size  and  geographical 
arrangement  of  the  system  to  be  monitored  and  controlled  as 
well  as  established  operating  philosophy  of  the  power  system. 

The  smaller  systems  are  almost  always  centralized  with  a single 
control  center.  Larger  systems  are  occasionally  configured  in 
a decentralized  manner  with  several  regional  data  collection 
points  and  a central  coordination  center. 

The  system  dispatcher,  aided  by  a modern  computer  control 
system,  will  be  able  to  achieve  the  full  benefits  of  intercon-* 
nected  operations.  Timely  participation  in  interchange 
transactions  will  ensure  that  resources  are  utilized  optimally 
in  pool  operations  with  attendant  economies  in  cost  savings 
shared  with  other  member  companies.  Billing  data  gathered 
automatically  by  the  computer  system  will  allow  the  dispatcher 
to  audit  the  actual  benefits  and  to  discover  any  opportunities 
for  additional  economic  benefits. 

A computer  system  providing  system  monitoring,  automatic 
alarming,  and  periodic  logs,  will  require  a minimum  of  manpower 
to  provide  service  to  the  member  cooperatives.  The  computer 
system  will  have  the  capability  to  expand  as  the  power  system 
grows  placing  only  minimal  additional  demands  on  system 
dispatcher  manpower. 

Additional  benefits  will  accrue  from  a complete  system  of  data 
acquistion  and  control.  System  dispatchers  will  be  able  to 
monitor  continuously  all  the  important  parameters  in  the 
generation  and  transmission  system  to  maintain  a high  level  of 
security  and  efficiency  of  operations.  In  case  of  emergencies, 
system  dispatchers  will  be  able  to  pinpoint  the  problem 
area,  assess  the  extent  of  the  disturbance,  evaluate  courses 
of  action  and  take  direct  control  actions  in  seconds.  Control 
decisions  will  be  made  with  confidence  derived  from  current 
information  of  all  affected  parameters.  A modern  man/machine 
interface  provides  the  system  dispatcher  with  data  displays 
organized  for  maximum  comprehension  in  various  levels  of  detail, 
and  with  a common  control  interface  that  further  minimizes  the 
possibility  of  error.  Outage  durations  will  be  reduced  and  the 
improved  service  to  customers  will  enhance  public  confidence 
in  the  Rural  Electric  Cooperatives. 
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B.  Purpose 


The  design  and  implementation  of  a power  control  and  energy- 
management  system  is  an.  undertaking  of  significant  proportions. 
There  is  exposure  to  many  disciplines  and  the  potential  for 
problems  is  substantial.  As  with  all  complex  engineering  tasks, 
the  definition  of  requirements  is  one  of  the  most  important 
phases  of  the  project.  Design  and  implementation  can  proceed 
in  an  orderly  manner  only  if  based  on  a complete  and  clearly 
stated  set  of  requirements.  The  purpose  of  this  bulletin  is  to 
serve  as  an  introduction  to  power  control  and  energy  manage- 
ment systems  and  to  present  certain  design  and  application 
guidelines  bearing  on  the  overall  implementation  of  the  control 
center  facility,  hardware,  and  software  design. 

C.  Scope 

The  engineering  work  required  to  place  into  operation  a new 
control  system  consists  of  several  distinct  phases.  This 
bulletin  presents  an  overview  of  power  control  and  energy 
management  system  functions,  operations,  design  guidelines, 
project  management,  training  and  related  activities. 

D.  Trends 


Modern  system  control  centers  which  have  been  placed  in  service 
since  the  start  of  the  1970's  and  also  those  which  are  in 
the  process  of  implementation  have  many  of  the  following 
features  and  functions : 

0 Heirarchial  structures  consisting  of  several  levels  of 
computer  systems 

° Dual  real-time  processors  or  multi-processors  plus  re- 
dundant peripherals 

° High-speed  digital  telemetry  and  data-acquisition  equip- 
ment 

° System-wide  instrumentation  of  electrical  quantities  and 
device  status 

° Color  CRTs  with  graphics  for  interactive  display 

° Dynamic  wallboard  group  display 

° Automatic  generation  control 

° Economic  dispatch  calculation 
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Automatic  voltage  ( VAR)  control 


° Supervisory  control  ("breakers,  capacitors,  transformer 
taps,  generating  unit  start-up  and  shutdown) 

° Security  monitoring 

0 State  estimation 

° On-line  load  flow 

° Steady-state  security  analysis 

° Optimum  power  flow 

° Automatic  system  trouble  anlaysis 

° On-line  abort- circuit  calculation 

° Emergency  control — automatic  load  shedding,  generator 
shedding,  line  tripping 

° Automatic  circuit  restoration 

° Programmable  remote  terminals 

There  is  no  control  system  that  has  all  of  the  functions  just 
enumerated.  This  is  to  be  expected.  Operating  problems  and 
philosophies  differ  due  to  different  networks,  generation 
resources,  and  structures  of  operating  responsibilities. 


II.  CONTROL  FUNCTIONS,  OPERATIONS,  AND  SUBSYSTEMS 


A.  Introduction 

The  terms  Energy  Control  or  Energy  Management  System  are 
used  in  the  same  context  as  Supervisory  Control  and  Data 
Acquisition  System.  The  functions  of  these  systems  are  virtual- 
ly synonymous^  or  can  be  made  such  that  they  are  indistinguish- 
able from  one  and  another. 

Throughout  our  electric  cooperatives  in  the  United  States  today, 
the  traditional  dispatchers  offices  are  giving  way  to  modern 
computerised  control  centers.  This  change  from  the  old  to  the 
new  is  not  merely  one  of  modernization  of  dispatching  or 
supervisory  control  to  a more  comprehensive  and  integrated 
approach  to  monitoring  and  controlling  a power  system. 

The  control  of  the  operating  process  can  be  divided  broadly 
into  two  groups:  those  that  operate  automatically,  and  those 
that  depend  on  the  action  of  an  operator.  Relay  initiation 
control  to  isolate  components  that  malfunction  fall  into 
the  automatic  category. 

With  the  development  of  telemetering  and  digital  computers, 
centralized  control  functions  became  possible.  Among  the  first 
parameters  selected  for  control  were  the  load  frequency  and 
the  level  of  power  exchange  with  neighboring  systems.  In  the 
case  of  load  frequency  the  total  load  of  all  generating  units 
of  the  system  was  controlled  to  keep  the  system  frequency 
within  specified  limits.  The  controlling  of  the  level  of 
power  exchange  with  neighbors  led  to  economic  dispatch 
whereby  power  is  scheduled  to  minimize  fuel  costs.  These  are 
some  of  the  centralized  control  functions  where  information 
from  many  locations  in  the  system  are  needed  in  the  decision 
or  control  process. 

Current  state-of-the-art  demands  that  system  operators  be 
involved  in  the  decision  making  process  and  similarly  for 
control  centers  to  exist,  real-time  information  must  be 
received  from  the  power  system.  The  data  acquis.it ion  system 
performs  this  function  and  the  man/machine  interface  displays 
the  information  to  the  operator.  The  overall  goal  of  the  man/ 
machine  interface,  through  proper  design  of  a Supervisory 
Control  System,  is  to  present  the  minimum  amount  of  information 
in  the  most  understandable  format  for  the  most  rapid  decision 
to  be  made . 
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B.  Power  System  Control 


A control  system  provides  a means  for  remotely  supervising  the 
operation  of  equipment  and  devices.  In  an  electric  power 
system,  supervision  is  conducted  from  a central  location  or 
dispatch  center.  The  supervised  equipment  and  devices  are 
located  remotely  in  substations  and  switchyards,  and  in  unat- 
tended hydro-electric  plants,  diesel-electric  plants,  and 
gas-turbine  electric  plants. 

The  term  "supervisory  control"  usually  implies  a method  of 
remote  control  and  indication,  utilizing  communi cat ions 
channels  such  as  microwave  radio,  VHF  radio,  powerline 
carrier  or  telephone  wirelines. 

A control  system  can  provide  any  or  all  of  the  following 
functions : 

° Control 

° Status  Indication 

° Alarms 

° Telemetering 

Control  can  be  applied  to  circuit  breakers,  transformer  tap 
changers,  capacitor  banks,  reactors,  unattended  power  plants 
and  other  apparatus.  Status  Indication  provides  information 
as  to  the  present  status  of  circuit  breakers,  tap  changers, 
switches,  equipment  and  other  apparatus.  Alarms  signal  the 
change  of  status  of  circuit  breakers,  switches,  equipment  and 
other  apparatus.  Alarms  also  signal  equipment  failure,  un- 
authorized entry,  and  extreme  excursions  in  temperature, 
voltage  and  other  quantities.  Telemetering  provides  informa- 
tion on  a continuous  basis  or  on  demand,  any  measurable 
quantity  (measurand)  including  but  not  limited  to,  voltage, 
amperes,  watts,  vars,  kilowatt  hours,  phase  angle  and  power 
factor . 

The  techniques  employed  in  supervisory  control  systems  have 
undergone  rapid  changes  in  the  last  decade  and  are  still 
undergoing  innovations.  Mechanical  relay-type  systems  are 
rapidly  being  supplanted  by  solid-state  systems.  The  earlier 
versions  of  solid-state  systems  employing  discrete  semicon- 
ductors have  given  way  to  integrated-circuit-oriented  systems. 
The  quiescent  mode  of  operation  is  being  superseded  by  the 
continuous-scan  mode.  Small  digital  computers,  called  central 
processor  units  (CPUs)  are  being  incorporated  into  supervisory 
control  systems  and  are  markedly  changing  conventional  super- 
visory concepts.  These  mini-computers  have  made  possible  what 
is  known  as  computer  oriented  real-time  Supervisory  Control 
and  Data  Acquisition  Systems,  abbreviated  SCADA. 
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The  goal  of  system  control  center  design  is  the  implementation 
of  security  control. 

Security  control  requires  the  proper  integration  of  both  auto- 
matic and  manual  control  functions,  i.e.,  a total  systems 
approach  with  the  human  operator  being  an  integral  part  of  the 
control  system  design.  Security  control  requires  that  all 
conditions  of  operation  be  recognized  and  that  control  deci- 
sions by  the  main  computer  system  must  be  made  not  only  when  the 
power  system  is  operating  normally,  but  also  when  it  is 
operating  under  abnormal  conditions. 

The  power  system  may  be  assumed  as  being  operated  under  two 
sets  of  constraints,  load  constraints  and  operating  constraints. 

The  load  constraints  impose  the  requirement  that  load  demands 
must  be  met  by  the  system.  The  operating  constraints  impose 
maximum  or  minimum  operating  limits  on  system  variables  and 
are  associated  with  both  steady-state  and  stability  limita- 
tions. Mathematically,  the  load  constraints  can  be  expressed 
in  the  form  of  the  familiar  load  flow  equations.  The  operating 
constraints  may  be  expressed  in  the  form  of  inequalities,  such 
as  on  equipment  loadings,  bus  voltage,  phase  angle  differences, 
generator  real  and  reactive  powers,  etc. 

The  conditions  of  operation  can  then  be  categorized  into  three 
operating  states — normal  (or  preventive),  emergency,  and 
restorative . 

A system  is  in  the  normal  state  when  the  load  and  operating 
constraints  are  satisfied.  It  is  reasonable  to  assume  that 
in  the  normal  state  the  power  system  is  in  a quasi  steady- 
state  condition.  For  any  given  time,  the  intersection  of 
the  load  constraints  and  the  operating  constraints  defines  the 
space  of  all  feasible  normal  operating  states.  The  power 
system  may  be  operated  anywhere  in  this  space. 

A system  is  in  the  emergency  state  when  the  operating  con- 
straints are  not  completely  satisfied.  Two  types  of  emergencies 
may  be  noted.  One  is  when  only  steady-state  operating  con- 
straints are  being  violated,  e.g.,  an  equipment  loading  limit 
is  exceeded  or  the  voltage  at  a bus  is  below  a desired  level 
The  other  is  when  a stability  operating  constraint  is  violated 
and  as  a result  of  which  the  system  cannot  maintain  stability. 
The  first  type  of  emergency  may  be  called  "steady- state  emer- 
gency" and  the  second  type,  "dynamic  emergency".  For  the 
moment,  however,  we  shall  not  distinguish  between  the  two 
types  of  emergency. 


II-3 


A system  is  in  the  restorative  state  when  the  load  constraints 
are  not  completely  satisfied.  This  means  a condition  of  either 
a partial  or  a total  system  shutdown. 

In  case  of  a partial  shutdown  the  reduced  system  may  he  in  an 
emergency  state.  This  is  the  start  of  a cascading  situation, 
and  if  uncorrected,  would  lend  to  a further  deterioration  of 
the  system. 

The  concept  of  three  operating  states  breaks  up  the  complex 
overall  operating  problem  into  three  operating  sub-problems 
with  different  control  objectives.  Of  primary  interest  and  of 
major  impact  on  the  design  of  system  control  centers  is  the 
control  done  in  the  normal  state.  It  is  basically  the  develop- 
ment and  implementation  of  functions  in  this  area  that  repre- 
sent the  state-of-the-art  in  system  control  centers.  Emergency 
and  restorative  controls  are  needed  for  a complete  security 
control  system,  but  so  far  their  implementation  at  control 
centers  has  been  very  limited  in  scope  and  in  ingenuity. 

The  effectiveness  of  security  control  depends  heavily  on  the 
control  done  during  the  normal  operating  state.  If  a system 
could  be  controlled  so  that  it  remains  normal  100%  of  the 
time,  then  all  the  load  constraints  would  be  met  without  any 
problem  and  there  would  exist  the  maximum  opportunity  for 
realizing  the  full  economic  benefits  of  sound  operating.  The 
objective  of  security  control  may  therefore  be  restated  as 
follows:  to  keep  the  power  system  operating  in  the  normal 

operating  state,  i.e.,  to  prevent  or  to  minimize  the  depar- 
tures from  normal  state  into  either  the  emergency  or  the 
restorative  state.  To  realize  an  effective  strategy  for 
carrying  out  this  objective,  let  us  look  more  closely  into  the 
concept  of  system  security. 

1.  The  Concept  of  System  Security 

System  security  may  be  considered  as  the  ability  of  a 
power  system  in  normal  operation  to  undergo  a disturbance 
without  getting  into  an  emergency  condition. 

The  system  is  then  said  to  be  "secure".  On  the  other  hand, 
a normal  operating  system  would  be  "insecure"  if  there 
were  a disturbance  which  could  bring  about  an  emergency 
operating  condition.  In  practice,  system  security  is  de- 
termined with  reference  to  an  arbitrary  subset  of  the 
complete  disturbance  set.  This  subset  is  called  the  "next- 
contingency"  set.  The  choice  of  the  composition  of  the 
next-contingency  set  is  dictated  by  the  probability  of 
occurence  of  the  contingency  within  the  next  short  period 
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of  time  (in  the  order  of  minutes ) and  the  consequences  to 
the  system  should  the  contingency  occur. 

In  most  power  systems  the  next-contingency  set  includes, 
as  a minimum,  the  following  types  of  disturbances: 

° Any  circuit  out 

0 Any  generating  unit  out 

° Any  phase-to-phase  or  3-phase  short  circuit 

Other  types  of  disturbances  may  be  added.  The  more  dis- 
turbances included  in  the  next  contingency  set  the  more 
stringent  the  system  security  requirements  become. 

For  a given  next  contingency  set,  the  set  of  all  normal 
operating  states  may  be  partitioned  into  two  disjoint 
subsets — secure  and  insecure . That  is,  a normal  operating 
system  is  either  secure  or  insecure.  For  security  control 
to  accomplish  its  objectives  of  preventing  or  minimizing 
departutres  from  the  normal  state  it  is  highly  desirable 
to  be  able  to  identify,  firstly,  whether  the  system  is 
normal  or  not,  and  secondly,  if  normal,  whether  the  system 
is  insecure  or  not,  and  thirdly,  if  insecure,  what  correc- 
tive action  may  be  recommended  to  make  the  system  secure. 

2.  Characteristics  of  Security  Control 

The  previously  stated  objective  of  system  control  center 
design  is  the  implementation  of  security  control  in  the 
broad  sense  of  integrating  all  required  automatic  and 
manual  functions  for  all  conditions  of  operation.  From 
this  prospective  the  general  patterns  can  be  seen  in 
which  system  control  centers  have  been  developing  in  the 
recent  years. 

The  necessity  for  integration  has  brought  together  the 
previously  separately  implemented  function  of  generation 
control  and  transmission  control  into  one  system.  For 
geographically  small  power  systems  the  integration  is 
carried  out  in  the  system  control  center.  For  large 
systems  or  systems  with  existing  regional  or  area  control 
centers  this  integration  is  accomplished  by  linking  the 
centers  at  various  levels  into  a computer  heirarchy. 

The  new  requirement  of  security  monitoring  alone  has 
necessitated  the  collection  of  a large  volume  of  real- 
time system  data  every  few  seconds  and  has  brought  about 
the  use  of  filtering  and  state  estimation  techniques. 
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In  addition,  the  integration  of  automatic  and  manual 
functions  is  being  manifested  in  the  form  of  advanced 
display  devices  and  techniques.  The  CRT  with  limited 
graphics  has  become  the  universal  man/machine  interface 
for  system  control  centers. 

3 • Functions  of  a Control  Center 


In  this  section  certain  of  the  real-time  functions  that 
are  generally  of  widespread  concern  to  system  operation 
are  summarized. 

a.  Automatic  Generation  Control  (AGC) 

The  function  of  Automatic  Generation  Control  (AGC)  is 
to  determine  the  generation  required  to  meet  the 
actual  system  load  and  to  allocate  this  generation 
among  the  regulating  units,  coordinating  the  require- 
ments of  regulation  with  the  desired  base  operating 
point  of  each  unit.  The  last  part  of  this  definition 
identifies  an  important  interface  between  AGC  and  seme 
other  function  which  calculated  the  desired  base  point 
or  settings.  Traditionally , the  base  settings  are  deter 
mined  by  the  economic  dispatch  function.  But  in  our 
concept  of  security  control  this  need  not  always  be 
the  case.  During  certain  operating  conditions,  other 
functions  such  as  security  analysis  or  emergency 
control  could  establish  the  desired  base  operating 
points . 

The  basic  AGC  algorithms,  i.e.,  the  calculation  of 
area  control  error  and  the  assignment  of  regulation 
to  each  unit  recognizing  the  desired  base  points,  are 
welL  known.  To  apply  these  algorithms  in  a system 
control  center  requires  the  addition  of  modules 
which  in  effect  interface  with  the  real-time  environ- 
ment. These  modules  should  initialize  the  AGC 
function,  coordinate  all  information  from  other 
programs  which  affect  AGC,  prepare  and  hand  off  to  the 
data  acquisition  subsystem  the  signals  to  be  sent  to 
the  plants,  and  communicate  with  the  display  subsystem 

The  use  of  plant  computers  communicating  with  the  sys- 
tem control  center  offers  flexibility  for  carrying 
out  the  AGC  function.  The  AGC  software  at  the  system 
control  center  sends  desired  signals  for  each 
regulating  unit  to  the  plant  computers. 
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The  plant  computers  act  as  local  closed-loop  control- 
lers for  each  unit.  The  control  algorithms  at  the 
plant  computers  recognize  the  individual  rate  of 
response  of  each  unit.  Over  the  same  data  links  the 
plant  computers  report  to  the  system  control  center 
every  second  the  control  status  of  each  unit  and  its 
short- -term  raise  and  lower  capability.  This  informa- 
tion is  used  by  the  AGC  algorithm  such  that  the  de- 
sired mw  requested  is  within  the  dynamic  capability 
of  the  unit.  The  computer-to-computer  link  also 
handles  special  requests  by  a unit  operator  to  place 
a unit  off  or  on  regulation  or  to  change  a unit's 
operating  limits. 

b.  Economic  Dispatch  Calculation  (EDC) 

Economic  Dispatch  Calculation  is  performed  every  few 
minutes  using  the  set  of  coordination  equations  which 
requires  that  the  incremental  cost  of  delivered  power 
from  each  generating  unit  to  an  arbitrary  reference 
point  to  be  the  same  for  each  unit.  The  incremental 
cost  of  delivered  power  for  a given  point  from  a 
generating  unit  is  equal  to  the  incremental  cost  of 
generated  power  multiplied  by  a penalty  factor. 
Traditionally,  the  penalty  factors  are  calculated  using 
transmission  loss  B-constants. 

In  present  day  control  centers,  B-constants  are 
usually  calculated  off-line  and  are  updated  very 
frequently.  There  is  an  economic  advantage  to  be 
gained  in  updating  B-constants  on-line  especially 
in  these  times  of  high  fuel  costs. 

In  centers  where  a real-time  load  flow  is  required 
for  other  reasons,  it  would  be  possible  to  calculate 
the  penalty  factors  on-line  by  adding  a real  power 
optimization  routine  thus  obtaining  an  optimum  power 
flow.  So,  every  time  there  is  a network  change 
or  when  the  system  load  has  changed  significantly 
in  magnitude  or  in  relative  distribution  between 
areas,  the  optimum  power  flow  runs  automatically  and 
a new  set  of  penalty  factors  is  passed  on  to  the  EDC. 
The  penalty  factor  calculation  requires  on  the  order 
of  35  to  45  seconds  to  complete.  This  is  the  total 
response  time  and  includes  the  network  configuration 
update,  3 to  h fast  decoupled  load  flows,  Jacobian 
calculation  at  the  optimum  solution  point,  calculation 
and  transfer  of  new  penalty  factors  to  the  data  base. 
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Although  EDC  should  be  made  only  for  those  units  which 
are  regulating,  it  is  desirable  to  make  another  cal- 
culation including  all  the  other  units  on  local 
control.  This  second-pass  EDC  is  made  everytime  the 
regular  EDC  is  run.  The  results  of  the  second-pass  EDC 
are  displayed  to  the  operator  so  that  he  may  manually 
direct  the  units  on  local  control  to  be  moved  closer 
to  their  optimum  generating  points.  Considerable 
additional  economy  may  be  realized  this  way. 

c . Supervisory  Control 

Supervisory  control  is  not  a new  operating  function. 

Its  integration  into  a system  control  is  new.  Since 
supervisory  control  is  a manual  function  it  is  exer- 
cised via  the  man/machine  interface  of  the  display 
subsystem.  The  integration  of  supervisory  control  of 
circuit  breakers  is  not  always  straightforward. 

The  common  approach  has  been  to  retain  this  function 
at  the  lower  level  and  merely  report  the  breaker 
status  to  the  central  or  higher  level.  Such  a struc- 
ture will  need  reexamination  of  the  interfaces  in  the 
event  that  there  would  be  a requirement  for  breaker 
control  from  the  higher  level.  An  example  of  this 
would  be  some  form  of  emergency  control  such  as  load- 
shedding or  system  splitting. 

When  there  is  a need,  the  control  center  may  also 
perform  supervisory  control  of  voltage  regulating 
devices  (SVC)  such  as  tap  changers,  capacitors,  and 
generator  voltage  regulators. 

d.  Automatic  Voltage/Var  Control  (AVC) 

The  automatic  control  of  system  voltage  and  of  var 
allocation  is  not  yet  in  wide  use  even  by  those 
companies  who  feel  they  need  it,  primarily  due  to  the 
absence  of  an  efficient  on-line  optimization  algorithm. 

The  AVC  regulates  the  voltage  profile  and  also  mini- 
mizes losses  due  to  reactive  power  flow.  The  control 
variables  are  generator  reactive  powers,  transformer 
taps,  shunt  capacitors,  and  shunt  reactors.  Ihe  con- 
trol is  a two-step  orientation.  Voltages  and  var  flows 
are  checked  periodically  and  when  there  is  any  devia- 
tion beyond  certain  tolerances  the  voltage  profile 
control  calculation  is  initiated.  At  less  frequent 
intervals  the  minimum  loss  calculation  and  control  is 
executed. 
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e . Security  Monitoring  (SM) 

Security  Monitoring  (SM)  is  the  on-line  identification 
and  the  display  of  the  actual  operating  conditions  of 
the  power  system.  This  one  function  has  made  the 
difference  between  the  traditional  dispatch  center 
and  the  modern  system  control  center.  SM  requires  a 
systemwide  instrumentation  on  a greater  scale  and 
variety  than  that  required  by  a center  without  SM. 

The  types  of  measurements  include:  MW  and  MVAR  flows, 
branch  currents,  bus  voltages  bus  MW  and  MVAR  injec- 
tions, frequencies,  energy  readings,  circuit  breaker 
status  or  operation  counts,  manual  switch  positions, 
protective  relaying  operations,  transformer  tap 
positions,  and  miscellaneous  substation  status  and 
alarms . 

The  SM  function,  in  general,  checks  the  analog  values 
against  limits  basically  to  determine  whether  the  sys- 
tem is  close  to,  or  at,  the  emergency  state.  The 
limit-checking  also  allows  some  kind  of  data  valida- 
tion and  the  rejection  of  incongruous  data.  Limit- 
checking is  done  as  often  as  the  data  is  brought  in 
which  is  usually  in  the  order  of  every  one  to  a few 
seconds. 

The  display  required  for  SM  entails  the  use  of  CRTs 
and  a large  number  of  display  formats.  The  dynamic 
wall  display  is  also  used  for  SM.  Part  of  the  SM 
function  is  the  on-line  determination  of  the  network 
topology.  In  most  cases,  it  is  sufficient  to  deter- 
mine the  network  configuration.  In  centers  where 
there  is  a direct  responsibility  for  transmission, 
switching  and  safety  is  a paramount  factor.  The 
SM  function  should  include  an  identification  of  the 
electrical  status  (energized  or  de-energized)  or 
every  physically  isolatable  segment. 

f . Static  State  Estimation  (SE) 

State  Estimation  (SE)  may  be  defined  as  a mathematical 
procedure  for  calculating,  from  a set  of  system 
measurements,  a "best"  estimate  of  the  vector  of  bus 
voltage  magnitudes  and  phase  angles  of  the  network. 

The  measurement  set  is  understood  to  contain  an  ade- 
quate degree  and  spread  of  redundancy  to  allow  the 
statistical  correlation  and  correction  of  the 
measurements , detect  and  preferably  identify  bad  data, 
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and  yield  calculated  values  for  non-telemetered 
quantities. 

Although  there  are  just  a few  control  centers  with  SE 
in  operational  use,  the  value  of  operation  of  this 
function  is  becoming  more  widely  acknowledged.  Recent 
specifications  for  control  centers  include  SE  as  part 
of  the  software  requirements.  As  presently  practiced, 

SE  is  used  for  the  following  purposes: 

° Bad  data  identification 

° Calculation  of  non-telemetered  or  missing  data 
0 Provide  inputs  to  security  monitoring  function 
° Provide  vector  of  bus  injections  for  an  on-line 
load  flow,  security  analysis,  and  bus  load  fore- 
casting 

g . On-line  Load  Flow  (OLF) 

An  on-line  load  flow  (OLF)  is  one  which  is  used  for 
real-time  functions  such  as  security  monitoring, 
security  analysis,  penalty  factor  calculation, 
and  may  also  be  used  for  study  purposes.  OLF  makes 
use  of  real-time  data. 

The  OLF  requires  a vector  of  bus  injections.  In  the 
general  case,  the  bus  injections  are  calculated  from 
statistical  data  obtained  on-line  and  some  off-line 
historical  information. 

The  bus  injections  may  also  be  obtained  from  the 
results  of  a state  estimation  program.  These  injec- 
tions may  be  used  as  they  are  or  normalized  to  pro- 
duce a set  of  load  distribution  factors.  These 
distribution  factors  may  be  projected  to  a future 
time  for  predictive  purposes. 

The  on-line  load  flow  is  a necessary  function  for 
system  control  centers.  It  should  not  be  interpreted, 
however,  as  supplanting  state  estimation.  As  we  have 
seen,  these  two  functions  serve  different  needs.  Since 
the  on-line  load  flow  uses  bus  injections  which  are 
statistical  in  origin,  the  ultimate  OLF  should  give 
results  with  some  kind  of  statistical  interpretation, 
i.e. , an  stochastic  load  flow.  We  are  not  yet  there 
with  the  present  state-of-the-art.  However,  the  basic 
formulation  of  the  OLF  for  penalty  factor  calculation, 
for  establishing  the  base  case  of  security  analysis,  and 
as  an  alternative  method  for  performing  contingency 
evaluation  is  of  current  value  at  system  control  centers. 
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h . Steady-State  Security  Analysis  (SA) 


The  first  function  of  security  analysis  (SA)  is  to 
determine  whether  the  normal  system  is  secure  or 
insecure.  The  second  function  is  to  determine  what 
corrective  action  strategy  would  be  taken  when  the 
system  is  insecure . 

The  first  function  is  commonly  known  as  contingency 
evaluation  since  by  definition,  the  security  of  a 
system  is  determined  with  reference  to  a set  of  next- 
contingencies.  In  present  state-of-the-art,  only 
steady-state  contingency  evaluation  is  done  at  system 
control  centers.  That  is,  the  emergency  condition  that 
is  to  be  avoided  is  overloading  of  equipment  or  poor 
bus  voltages. 

Security  analysis  as  presently  modeled  requires  an 
up-to-date  equivalent  of  the  external  interconnection. 
So  far,  the  only  equivalent  available  and  used  at 
control  centers  have  been  traditional  equivalents 
which  have  several  recognized  shortcomings.  There  is 
now  a revised  interest  in  equivalents  for  security 
analysis.  Two  basic  types  are  emerging:  topological 
and  non-topological.  Topological  equivalents,  like 
the  traditional  equivalent,  are  derived  from  prior 
knowledge  of  the  detailed  external  system.  Non- 
topological  equivalents  require  no  physical  network 
information  but  are  derived  from  real-time  measure- 
ments via  stochastic  approximation  techniques.  Work 
on  non-topological  equivalents  is  continuing  and 
initial  results  have  been  reported  in  the  literature. 

As  discussed  previously,  the  space  of  feasible  normal 
states  may  be  partitioned  into  secure  and  insecure 
regions.  This,  of  course,  is  a dynamic  situation.  As 
the  system  generation,  load,  and  topology  change,  so 
does  the  space  of  normal  states  and  so  does  the 
boundary  between  secure  and  insecure  regions.  In  fact, 
either  region  could  be  a null  subspace.  Clearly,  as 
system  conditions  change,  the  contingencies  in  the 
next  -contingency  set  which  yields  insecure  operating 
points  also  change.  At  times  the  system  is  very  strong 
such  that  no  contingency  in  the  next  contingency  set 
can  cause  an  emergency,  the  insecure  region  is  null, 
and  contingency  evaluation  is  not  required.  At  other 
times  only  certain  contingencies  need  be  evaluated. 
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Presently,  we  do  not  have  any  really  satisfactory 
techniques  for  accomplishing  security  analysis.  We 
are  thus  compelled  to  use  a fixed  list  of  contingen- 
cies, perhaps  with  some  spare  room  for  operator- 
specified  contingencies.  Since  the  security  analysis 
routines  could  impose  a large  computational  burden, 
in  certain  centers  the  next  contingency  list  is 
pared  down  to  a small  number  of  items.  This  is  not 
always  possible.  There  could  still  be  enough  contin- 
gencies to  cause  loading  problems  of  computer  re- 
sources. Part  of  the  problem  is  the  requirement  that 
security  analysis  be  run  periodically,  2k  hours  a day. 
An  alternative  approach  would  be  to  use  the  Security 
Monitoring  function  to  determine  whether  or  not  there 
is  a need  for  SA.  This  could  be  based  on  arbitrary 
levels  of  line  loadings. 

C.  The  Computer  Subsystem 

The  Computer  Subsystem  is  the  primary  tool  in  the  control 
center.  It  is  the  heart  of  the  operation  - controlling 
generation  and  transmission,  gathering  and  analyzing  data, 
generating  logs  and  updating  displays.  All  these  real-time 
operations  are  based  on  operator  inputs  and  data  acquired 
utilizing  logic  programmed  into  the  computer.  The  initial 
capability  and  ultimate  expanded  capability  of  the  computer 
subsystem  is  a major  factor  determining  the  responsiveness  of 
the  control  system  and  the  ultimate  workload  of  the  control 
center . 

By  acquainting  the  reader  with  the  computer  hardware  and 
system  software,  the  advantages  and  disadvantages  of  various 
options,  and  functions  and  features  required  in  the  unique 
environment  of  real-time  control  center,  it  is  hoped  to  help 
the  prospective  control  center  purchaser  better  understand 
the  design  guidelines  and  requirements  of  section  III. 

1 . Overview  of  Computer 

The  basic  hardware  elements  of  the  computer  subsystem 
include  the  Central  Processing  Unit  (CPU),  the  Input/ 

Output  Processor  (IOP),  Main  Memory,  and  Peripherals.  The 
CPU  is  the  master  controller  of  the  computer,  and  it  per- 
forms the  arithmetic  operations  and  makes  the  logical 
decisions.  The  Main  Memory  is  the  storage  location  for 
the  data  and  the  programs  that  use  the  data.  The  IOP 
transmits  data  between  the  Main  Memory  and  the  Peripherals, 
while  the  Peripherals  convert  the  data  into  an  output 
format  for  human  intelligence,. or  input  for  computer 
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utilization.  This  basic  hardware  is  one  of  the  operating 
system's  resources.  The  CPU  under  direction  of  the  oper- 
ating system  will  call  application  programs  which  in  turn 
will  maintain  the  data  base  and  control  the  power  system. 

Computers  are  organized  along  two  major  architectural 
systems.  In  one  case,  the  computer  consists  of  a multiple 
number  of  busses.  One  bus  for  the  CPU  and  other  busses  for 
each  IOP.  Attached  to  the  IOP  are  the  various  Peripherals 
that  are  part  of  the  computer  subsystem.  The  busses  are 
connected  to  Main  Memory  through  multiports  permitting 
the  CPU  and  the  IOPs  to  operate  independently  and 
simultaneously.  In  the  second  case,  there  is  one  bus  that 
connects  the  CPU  and  all  the  IOPs  to  Main  Memory.  The 
Peripherals  are  attached  to  the  IOP's.  In  this  case,  the 
access  to  memory  by  the  CPU  and  the  IOP's  is  done 
sequentially  on  a priority  basis.  This  permits  a common 
design  for  the  element's  interfaces  to  the  single  bus. 

The  advantage  of  one  architectural  system  over  the  other 
is  not  inherent  in  the  design.  The  sequential  operation 
of  the  single  bus  system  can  overcome  the  possible  advan- 
tage of  the  simultaneous  operation  of  the  multibus 
system  by  being  much  faster  and  simpler  in  design. 

While  most  computer  subsystems  have  the  same  basic 
elements,  there  is  a difference  in  their  capabilities  and 
performance.  The  major  factors  contributing  to  perform- 
ance are  word  size,  maximum  Main  Memory,  Peripherals, 

Bulk  Memory,  and  I/O  Bandwidth. 

The  range  of  computer  word  size  is  from  8 bits  to  64  bits 
though  the  majority  of  computers  in  Electric  Power 
Applications  are  l6,  24,  and  32  bit  words.  Main  Memory 
capabilities  may  range  from  32  K words  to  about  1024  K 
words  (where  K equals  1024).  The  more  usual  values  have 
been  between  64  K words  and  128  K words  though  the  trend 
is  upward. 

Bulk  Memory  is  composed  of  Peripherals  that  are  attached 
to  IOPs.  Bulk  Memory  is  critical  to  the  performance  of 
the  computer  subsystem  and  works  in  conjunction  with 
Main  Memory.  Its  size  is  measured  in  millions  of  bytes 
(Megabytes)  where  a byte  is  8 bits.  Bulk  Memory  capacity 
has  usually  been  three  to  twelve  million  bytes  but  the 
trend  is  for  greater  capacities,  as  high  as  40  to  80 
million  bytes. 
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The  capability  to  transfer  this  large  amount  of  data 
between  Bulk  Memory  and  Main  Memory  has  put  heavy  demands 
on  I/O  processing  throughout.  I/O  Bandwidth  measures  in 
kilobytes/second  is  the  capability  of  the  I/O  to  pass 
data  between  memory  and  its  attached  Peripheral.  The  usual 
values  for  I/O  Bandwidth  have  been  from  300  kilobytes  to 
1000  kilobytes  per  second  but  the  computer  subsystems 
for  control  centers  are  now  exceeding  10,000  kilobytes 
per  second. 

2.  The  Central  Processing  Unit  (CPU) 

The  CPU  as  its  name  implies  is  the  center  of  the  computer 
subsystem.  It  interprets  instructions,  compares  values, 
accesses  memory,  and  controls  the  flow  of  data  in  and  out 
of  1/0  devices.  Word  size  has  a very  important  effect  on 
the  operation  of  the  CPU.  An  instruction  word  usually 
consists  of  four  parts:  (l)  an  operation,  (2)  a Main 
Memory  reference  address,  (3)  a register  address,  and 
(4)  modifiers.  A l6  bit  word  may  use  8 bits  for  address, 

4 bits  for  operation,  and  b bits  for  a modifier  such  as  in- 
dex, indirect  address  and  displacement.  The  register  address 
is  predefined  and  therefore  it  is  not  needed.  A 2b  bit 
word  may  use  lU  bits  for  address,  6 bits  for  operation, 

3 bits  for  register  address  and  indexing,  and  one  for 
modifier.  A 32  bit  word  may  have  17  bits  for  address,  7 
bits  for  operation,  k bits  for  register  address,  3 for 
index  register,  and  one  for  modifier. 

The  maximum  amount  of  Main  Memory  that  can  be  directly 
addressed  is  limited  to  the  reference  address  bits  in  the 
instruction  word.  Thus  8 bits  can  directly  address  up  to 
256  words,  l4  bits  can  directly  address  up  to  l6  K words 
and  17  bits  can  directly  address  up  to  128  K words.  By 
means  of  second  instruction  words,  indirect  addressing, 
indexing,  using  displacement  registers,  and  extending  bits, 
the  maximum  directly  addressable  Main  Memory  is  usually 
between  6b  K words  to  256  K words. 

A popular  way  to  overcome  address  limitations  imposed  by 
the  CPU  is  to  employ  memory  mapping.  Memory  mapping  may 
be  accomplished  by  a number  of  different  methods  but  most 
use  part  of  the  reference  address  of  the  instruction  word 
to  point  to  another  register  whose  contents  are  appended 
to  the  reference  address  to  permit  addressing  larger  Main 
Memory.  This  also  gives  the  added  benefit  of  permitting 
programs  to  be  segmented  into  different  available  areas 
of  Main  Memory  and  still  appear  contiguous  to  the  oper- 
ating system,  thus  permitting  more  efficient  allotment  of 
Main  Memory. 
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Instruction  set  size  can  be  determined  from  the  number  of 
operation  bits,  but  by  means  of  modifiers  under  special 
cases  additional  instructions  may  be  inferred.  The 
number  of  registers  that  are  directly  available  to  the 
CPU  are  also  derived  from  the  instruction  word.  Again, 
it  is  possible  to  extend  this  by  such  means  as  a modifier 
or  use  of  a second  word. 

Instruction  times  for  the  simple  direct  operation  such  as 
load,  store,  add,  etc.  for  computer  subsystems  commonly 
used  in  the  ECC  are  1.1  to  1.4  microseconds  and  somewhat 
independent  of  computer  word  size.  However,  the  execution 
of  programs  containing  these  instructions  may  vary  by 
more  than  50%  because  the  large  word  size  machines  may  use 
fewer  instructions.  Also  contributing  to  the  faster  exe- 
cution times  are  such  sophisticated  techniques  as  look- 
ahead which  permits  more  than  one  instruction  in  the 
operation  cycle,  register-to-register  operation  to 
eliminate  access  time  to  Main  Memory,  and  the  use  of 
firmware  or  hardware  is  a typical  requirement  for  systems 
providing  unit  dispatch  and  commitment  and  security 
functions . 

Firmware  which  is  literally  burning  in  a program  on  an 
integrated  circuit  (IC)  chip  is  a cross  between  hardware, 
where  everything  is  done  with  components,  and  software, 
where  the  operation  is  done  by  a program.  Firmware  is  not 
only  used  to  perform  specialized  instructions,  but  to 
emulate  the  whole  CPU.  The  use  of  firmware  permits  a 
reduction  in  manufacturing  cost  and  an  improvement  in 
computer  operation.  The  emulation  of  an  existing  CPU 
instruction  set  permits  software  that  has  been  developed 
and  proven  to  be  used  without  modification.  Thus,  a com- 
puter Whose  CPU  is  emulated  by  means  of  firmware  may  be 
less  expensive,  operates  faster  and  utilizes  known  and 
proven  programs. 

A CPU  used  in  an  ECC  should  have  real-time  operational 
features  such  as  Real-Time  Clocks,  Multilevel  Priority 
Interrupts,  and  Rapid  Context  Switching.  The  Real-Time 
Clocks  permit  the  start  of  periodic  function  to  occur  at 
specific  instants  and  be  related  to  real-time.  The  use  of 
Multilevel  Priority  Interrupts  provides  for  rapid  response 
to  external  events,  with  each  interrupt  identified  and 
responding  according  to  its  priority.  When  responding  to 
an  interrupt  initiated  event,  the  CPU  must  use  Rapid 
Context  Switching  to  preserve  the  current  enviroment  and 
set  up  the  new  environment  within  a minimum  time. 
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3 . Use  of  Busses 


The  CPU  works  with  other  parts  of  the  computer  by  means  of 
busses  that  carry  data  as  well  as  control  and  status 
information.  The  size  and  speed  of  the  bus  varies  and 
obviously  the  faster  the  bus  and  the  more  information 
carried  in  parallel,  the  faster  the  overall  operation  of 
the  computer.  Busses  connect  the  CPU  to  Main  Memory  and  to 
the  I/O  processor  and  may  be  one  byte  or  more  wide. 

There  are  two  basic  types  of  operations  on  the  bus: 
asynchronous  and  synchronous . An  asynchronous  bus 
requires  an  answer  back  from  the  device  or  component 
addressed  and  thus  usually  is  slower,  but  permits  wider 
tolerance  in  cable  lengths,  placement  of  elements  within 
the  system,  and  response  time.  A synchronous  bus  may  be 
faster,  but  each  operation  is  run  from  a master  clock 
which  requires  tight  tolerances  of  cable  and  wire  lengths, 
relatively  less  flexible  arrangement  of  computer  elements, 
and  very  exact  response  times  because  of  possible  problems 
in  propagation  and  dispersion. 

4.  Main  Memory 

There  are  two  types  of  Main  Memory  found  in  ECC  computer 
subsystems.  They  are  core  memory  and  solid  state  memory. 

The  core  memory  is  the  older  type  and  has  been  in  general 
use  for  more  than  15  years,  constantly  being  improved 
in  its  speed  of  operation  and  reliability.  The  cost  of 
core  memory  over  the  years  has  steadily  dropped.  Solid 
state  memory  design  concepts  are  not  new,  but  only  recently 
has  solid  state  memory  been  found  in  computers  for 
electric  power  applications. 

Core  Memory  has  one  distinct  advantage  over  solid  state 
memory  in  that  it  is  nonvolatile,  it  does  not  lose  its 
information  when  power  is  turned  off.  Solid  state  memory 
is  volatile,  but  this  becomes  less  important  with  the 
various  power  backup  methods  that  have  evolved. 

In  other  respects  the  specification  for  core  memory  and 
solid  state  memory  are  very  similar.  Access  time  for  core 
memory  ranges  from  250  nanoseconds  to  1200  nanoseconds, 
while  solid  state  memory  may  not  be  much  lower  than 
250  nsec.  However,  more  importantly,  core  memory  is  per- 
forming as  best  as  could  be  expected  from  its  design; 
while  solid  state  memory  appears  to  be  capable  of  much 
better  performance.  This  includes  access  time,  packing 
density,  cost  per  bit,  and  reliability. 
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The  need  for  greater  packing  density,  lower  cost,  faster 
access  time  and  greater  reliability  is  due  to  the  ever 
increasing  demand  put  on  Main  Memory  by  the  requirements 
of  electric  power  applications. 

Main  Memory  in  a real-time  computer  subsystem  should  have 
a provision  for  error  checking  when  information  is  read 
from  memory.  Two  types  of  error  checking  are  usually  found; 
(l)  single  bit  parity  checking,  and  (2)  multibit  error 
checking  and  correction. 

Parity  checking  is  normally  found  in  core  and  solid  state 
memory  but  multibit  error  checking  and  correction  is 
usually  found  only  in  solid  state  memory  systems.  Solid 
state  memory  can  more  readily  add  the  extra  bits  needed 
for  error  checking  and  correction  and  it  usually  needs 
this  enhancement  for  better  reliability. 

Since  Main  Memory  cannot  be  indefinitely  expanded  to  hold 
all  the  needed  programs  and  data  required  by  the  ECC , Main 
Memory  is  divided  into  resident  and  overlay  areas.  Resident 
area  holds  those  programs  and  their  data  which  must  be  in 
Main  Memory  all  the  time  because  of  their  frequent  use  and 
importance  to  be  completed  within  a very  restrictive  time 
frame.  The  overlay  area  is  used  by  programs  which  are 
brought  in  from  bulk  memory  when  needed  and  thus  more 
than  one  program  may  overlay  the  same  Main  Memory  area. 

Main  Memory  size  is  usually  determined  by  the  requirements 
for  resident  programs  and  data,  and  the  largest  program 
needed  in  the  overlay  area. 

Main  Memory  protection  is  required  in  real-time  computer 
subsystems  to  permit  the  concurrent  operation  of  the  real- 
time programs  with  study  and  other  support  programs . Memory 
protection  which  may  be  controlled  by  hardware  or  software, 
or  both,  provides  access  protection  of  Main  Memory  and 
prevents  inadvertent  destruction  of  critical  programs. 

I/O  Equipment 

In  order  for  the  outside  world  to  communicate  with  the 
computer  subsystem,  Input /Output  Equipment  is  needed. 
Methods  utilized  include  special  processors  called  I/O 
processors,  intelligent  controllers,  and  direct  I/O. 

Only  the  direct  I/O  is  required  to  be  under  the  constant 
control  of  the  CPU.  The  I/O  equipment  is  tied  to  the 
CPU  and  Main  Memory  by  means  of  busses  which  send  and 
receive  data,  control,  and  status  information. 
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I/O  processors  are  specialized  processors  .that  may  be 
able  to  handle  large  numbers  of  input /output  devices 
independently  of  the  CPU.  They  usually  consist  of  a 
number  of  channels,  8,  l6,  32,  in  which  there  is  a 
different  device  on  each  channel.  All  channels  may  be 
operated  simultaneously.  The  only  limitation  is  the 
bandwidth,  or  number  of  bytes  being  transferred  by  the 
I/O  processors.  To  effectively  increase  the  bandwidth 
more  I/O  processors  may  be  added  to  the  computer  subsystem. 
Each  processor  may  have  its  own  access  or  port  to  Main 
Memory.  In  some  designs  the  I/O  processors  do  not  have 
their  own  memory  port,  but  share  data  with  other  busses 
to  memory  in  which  case  the  effective  bandwidth  is  reduced 
by  10  to  20%. 

The  I/O  processor  can  operate  all  its  channels  concurrently, 
sorting  out  which  is  to  receive  or  send  data.  The  I/O 
processor  checks  for  any  errors,  determining  where  the 
data  is  to  go  and  stopping  and  individual  channel  when  the 
transfer  is  completed  in  that  channel.  It  informs  the  CPU 
when  its  transfer  is  completed,  sending  the  CPU  the  status 
of  the  channels  performance. 

Intelligence  controllers  have  similar  functions  as  the  I/O 
processors,  but  are  organized  in  a different  manner.  Each 
controller  contains  a microprocessor  which  is  programmed 
in  firmware  to  perform  the  input /output  functions  for 
that  controller  and  its  device.  Thus,  each  intelligent 
controller  must  be  programmed  specially  for  its  associated 
I/O  equipment.  The  advantage  of  the  intellingent  controller 
is  that  no  additional  I/O  hardware  is  needed  than  is  used 
by  the  computer  while  an  I/O  processor  must  be  designed 
and  installed  with  the  capabilities  for  its  ultimate 
capacity.  However,  there  is  no  effective  means  to  increase 
the  bandwidth  of  the  I/O  with  intelligent  controllers 
since  they  all  operate  on  one  bus  and  therefore  the 
computer  subsystem  must  have  sufficient  I/O  bandwidth 
built  into  its  original  device  for  its  ultimate  applica- 
tion. 

Direct  I/O  under  control  of  the  CPU  is  not  normally  used 
for  the  same  functions  that  are  used  for  the  I/O  processor 
or  intellegent  controller.  The  Direct  I/O  brings  in  or 
sends  out  the  data  through  the  CPU  and  therefore  burdens 
the  CPU  with  its  operations.  The  Direct  I/O  is  best  suited 
for  data  that  is  limited  to  a few  words  or  even  to  a few 
bits  within  a word.  Its  primary  function  is  to  enable  the 
CPU  to  gain  quick  access  to  the  outside  world  and  to 
immediately  interpret  the  information.  Thus,  inputs  from 
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operator  panels  may  be  handled  through  the  Direct  I/O. 

Other  possible  functions  are  output  to  mapboards  to  show 
change  in  status  and  to  recorders  to  update  analog 
values.  The  enabling  or  disabling  of  a device  for  backup 
or  failover  may  also  be  performed  through  the  Direct  I/O. 

The  I/O  processor  and  the  Intelligent  controllers  usually 
handle  larger  streams  of  data  such  as  those  from  magnetic 
tape,  card  reader,  and  line  printer  peripherals.  Bulk  stor- 
age devices  and  CRT  displays  are  also  functions  that  use 
the  I/O  processors  or  intellegent  controllers.  Whenever 
the  data  stream  is  long  compared  to  the  overhead  of  the 
CPU  for  setting  up  the  I/O  processor  or  intelligent 
controller,  it  is  advantageous  to  use  this  method.  In 
cases  such  as  data  acquisition  from  remote  terminals,  the 
advantage  of  this  method  over  Direct  I/O  is  not  as  obvious. 
Since  the  length  of  the  stream  of  data  varies  for  differ- 
ent applications,  both  methods  have  been  employed.  It 
should  be  noted  that  the  I/O  processor  and  intelligent 
controllers  always  have  the  distinct  advantage  of  doing  all 
the  functions  of  the  Direct  I/O  without  adding  directly 
to  the  burden  on  the  CPU. 

6.  Bulk  Memory 

One  of  the  most  important  devices  within  the  I/O  equipment 
group  is  the  Bulk  Memory.  Bulk  Memory  provides  the  perma- 
nent storage  of  all  programs  in  Main  Memory  resident  as 
well  as  the  overlay  area.  Included  in  Bulk  Memory 
storage  is  the  data  base,  historical  files,  operating 
system,  and  temporary  storage  for  overlay  area  programs. 

Two  major  types  of  Bulk  Memory  devices  are  the  Fixed  Head 
Disc  (FHD)  and  the  Movable  Head  Disk  (MHD).  The  FHD  has 
one  magnetic  head  per  track  with  both  read  or  write 
capability;  while  the  MHD  has  one  magnetic  head  per  sur- 
face which  is  moved  from  track  to  track.  The  FHD  can 
start  to  transfer  data  to  or  from  the  disk  aS  soon  as  the 
segment  or  sector  of  the  track  reaches  the  head.  The  MHD 
must  move  the  head  to  the  track  of  interest  and  then 
wait  for  the  sector  to  pass  under  the  head. 

FHD  may  have  8.5  millisec  to  IT  millisec  average  access 
time  which  is  the  wait  time  between  requesting  the  data 
and  start  of  transfer  of  data.  Average  access  time  is  one- 
half  a maximum  access  time  and  under  many  circumstances 
average  access  time  can  be  reduced  or  eliminated  by  means 
of  s imp le  alg  or i thm . 
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MHD’s  have  average  access  time  of  30  to  50  millisec  which 
is  the  combination  of  the  average  time  to  move  from  one 
track  to  another  and  the  average  time  for  the  sector  to 
reach  the  head.  The  maximum  access  time  is  double  the  av- 
erage access  time  and  there  is  no  simple  algorithm  to  re- 
duce the  value  to  zero. 

In  addition,  FHD  may  have  write  protect  switches  which 
prevent  groups  of  magnetic  heads  from  writing  on  the  disk 
without  interfering  with  their  ability  to  read  from  these 
same  tracks.  MHD's  do  not  usually  have  such  features 
since  the  head  moves  over  a large  number  of  different 
tracks . 

FHD  usually  ranges  in  size  from  less  than  one  megabyte 
to  about  20  megabytes  while  MHD’s  are  sized  from  2 mega- 
bytes to  over  100  megabytes.  Transfer  rates  of  the  two 
devices  are  relatively  similar;  the  FHD  ranges  from  250 
kbytes/sec  to  almost  1 megabyte/sec  while  the  MHD  is  frcan 
350  kbytes  to  1.2  megabytes  per  second. 

The  cost  of  an  FHD  may  be  over  5 to  10  times  more  than  an 
MHD,  for  comparable  size  of  the  Bulk  Memory.  Comparing 
the  FHD  to  Main  Memory  the  FHD  is  about  40  times  less 
expensive  per  byte. 

Because  of  the  faster  access  time  inherent  in  the  FHD,  the 
capability  to  protect  certain  tracks  by  means  of  write 
protect  switches,  and  the  higher  cost  per  megabyte  for 
a FHD,  the  choice  of  Bulk.  Memory  has  to  be  made  according 
to  the  requirements  of  the  ECC.  Where  high  capacity  is 
needed  and  slower  access  time  can  be  tolerated,  the  lower 
cost  MHD  may  be  the  better  choice;  but  where  faster 
access  times  are  a necessity  and  the  write  protection  re- 
quired, then  the  FHD  is  preferable.  In  many  ECC  centers 
both  are  used,  and  their  assignment  is  based  on  the 
requirements  of  the  applications. 

A third  type  of  Bulk  Memory  is  bulk  core  or  solid  state 
memory  which  is  inexpensive  memory  but  formatted  to  be 
similar  to  an  FHD.  The  access  time  is  always  almost  zero 
and  the  transfer  rate  can  be  as  high  as  1 to  b megabytes/ 
sec.  Its  cost  is  approximately  4 times  less  than  Main 
Memory.  The  primary  function  of  bulk  core  would  be  to 
work  with  the  Main  Memory  overlay  areas  and  to  provide  fast 
access  and  high  transfer  rates  to  large  programs  that 
would  otherwise  need  undue  amounts  of  resident  Main 
Memory . 
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7.  Long  Term  Storage 


The  CPU,  Main  Memory,  I/O  equipment,  and  Bulk  Storage 
have  been  part  of  the  real-time  function  of  the  computer 
subsystem.  They  are  considered  critical  to  the  operation 
of  the  ECC.  The  long-term  storage  device  while  obviously 
important  is  not  usually  part  of  the  real-time  function. 
These  devices  include  magnetic  tape,  card  reader  and 
punch,  paper  tape  reader  and  punch.  They  provide  the 
program  source  and  object  code  storage  as  well  as  the 
data  storage  and  may  be  used  for  system  dumps  of  memory. 

For  systems  found  in  energy  control  centers,  magnetic 
tape  and  cards  are  usually  used;  while  paper  tape  is 
used  only  for  very  special  circumstances . Paper  tape  is 
much  too  slow  a medium,  usually  transferring  data  at  300 
to  1000  bytes  per  second.  Given  the  size  of  systems  at 
the  ECC  where  Main  Memory  may  be  128  K words  and  Bulk 
Memory  over  10  megabytes,  it  can  be  seen  that  it  could 
take  hours  to  transfer  programs  and  data  in  or  out  of 
the  computer. 

Magnetic  tape  specifications  include  the  tape  speed  in 
inches  per  second  (ips)  and  recording  density  in  bytes  per 
inch  (bpi) . Additional  specifications  include  the  record- 
ing method,  which  may  be  either  non-return  to  zero  (NRZl) 
or  phase  encoded  (PE),  and  the  recording  format,  which 
may  be  7 track  or  9 track.  Most  tape  units  operate  at 
37-5  ips,  ^5  ips  or  75  ips  with  a recording  density  of 
800  bpi  or  1600  bpi,  using  NBZI  with  800  bpi  and  PE  with 
1600  bpi.  The  almost  universal  format  is  IBM  compatible 
9 track  in  which  8 tracks  are  data  and  1 track  is  parity. 
Tapes  recorded  at  one  speed  may  be  read  at  another  speed, 
but  the  magnetic  tape  unit  must  use  the  same  recording 
density,  recording  method,  and  format. 

Magnetic  tape  drive  units  use  two  methods  for  buffering 
the  tape  between  reels.  The  lower  speed  units  use  mech- 
anized arms  to  take  up  the  slack  between  reels  while 
higher  speed  units  provide  vacuum  columns.  The  vacuum 
column  is  preferred  over  the  mechanized  arm  because  it 
reduces  wear  on  the  tape. 

Changes  to  programs  or  to  the  data  base  is  usually  done 
via  the  card  reader  by  cards  that  have  been  manually 
punched  on  a keypunch.  Card  readers  transfer  between  100 
to  1500  cards  per  minute  which  can  provide  from  200  to 
300  bytes/second.  As  can  be  readily  seen,  this  is  not  a 
feasible  procedure  for  reading  whole  programs  into  comput- 
er systems,  but  when  a small  number  of  cards  are  involved. 
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it  provides  a very  reliable  method.  The  most  common  pro- 
cedure is  to  use  the  magnetic  tape  unit  to  load  a computer 
with  all  its  programs  and  data  base.  The  update  or  mod- 
ification information,  once  read  into  the  computer  via 
card  reader,  is  merged  with  the  information  already  in  the 
computer  and  a new  program  or  data  base  can  be  dumped 
onto  magnetic  tape  for  long-term  storage. 

8.  Line  Printer 

Line  printers  provide  programmers  with  hard  copies  of  the 
programs  and  data  stored  in  the  computer.  They  are  also 
used  for  output  of  large  volume  logs  for  historical 
purposes  or  records.  They  may  have  additional  functions 
such  as  diagnostic  printout  or  backup  to  on-line  loggers. 
Normally  the  line  printer  is  not  considered  part  of  the 
real-time  functions  of  the  ECC,  but  is  very  important  to 
the  update,  modification  and  maintenance  of  the  system. 

Line  printers  are  specified  by  the  number  of  lines  per 
minute  printed  which  varies  frcrn  200  lines  to  1200  lines 
per  minute.  Because  of  the  heavy  usage  and  the  large 
volume  of  data  printed,  impact  hammer  type  is  preferred. 
However,  at  the  lower  speed, impact  dot  matrix  printers 
may  sometimes  be  used.  The  impact  hammer  type  printer 
noise  level  is  such  that  the  manufacturers  must  encase 
the  printer  in  a noise  reduction  enclosure.  The  noise 
level  is  reduced  to  below  that  of  an  office  typewriter. 

Printers  normally  have  64  character  set , print  up  to 
132  columns,  take  paper  of  various  widths  up  to  19  inches, 
print  6 lines  per  inch,  each  line  having  10  characters 
per  inch,  and  provide  a format  tape  to  permit  automatic 
page  and  line  adjustment. 

9 . Programmer  I/O  Devices 

Programmer  1/0  Device  is  usually  either  a KSR  (Keyboard 
Send/Receiver)  or  a video  terminal.  It  is  used  for 
programmer  control  and  communication  and  gives  a hard  copy 
or  visual  display  of  all  messages  between  programmer 
and  computer.  The  Programmer  I/O  Device  may  be  used  for 
program  checkout  error  messages  and  control  of  the  comput- 
er during  the  maintenance  period.  It  should  not  be  used 
to  dump  extensive  programs  from  the  computer. 

The  KSR  prints  from  10  to  30  characters  per  second  while 
the  video  terminal  may  be  able  to  operate  up  to  10  times 
faster.  When  a hard  copy  device  is  attached  to  the  video 
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terminal  its  output  speed  is  limited  by  the  printing 
speed  of  the  hard  copy  device. 

The  KSR  prints  a 72  to  80  character  line  with  6 lines  per 
inch.  The  video  terminal  is  capable  of  displaying  up  to 
2b  lines,  each  line  72  to  80  characters  wide.  The  character 
set  commonly  used  by  both  is  the  USA  standard  code  for 
Information  Interchange . (ASCII) . 

Every  computer  system  must  have  an  I/O  Programmer  Device 
in  order  to  be  able  to  start-up  and  be  maintained.  The 
choice  of  device  varies  widely  and  depends  mostly  on  the 
preference  of  the  user. 

10.  Physical/Environmental  Requirements 

a.  Environment 


The  temperature  and  humidity  requirements  in  the  Con- 
trol Center  are  most  stringent  for  the  computer 
subsystem.  The  computer  subsystems  usually  found  in 
Contrgl  Centers  have  upper  temperature  specifications 
of  32  C,  though  some  may  go  as  high  as  4l°C.  The 
lower  temperature  boundary  is  very  rarely  important 
because  the  computer  self -heat  will  maintain  the 
minimum  temperature.  Beside  the  upper  temperature 
boundary,  many  computer  subsystems  must  have  con- 
trolled temperature  change  which  may  be  in  the  range 
of  12°C  to  9°C  per  hour.  Though  the  operating  temper- 
ature range  may  be  large,  often  the  variation  from 
the  center  temperature  once  established  is  less  than 
the  overall  operating  temperature  range.  The  most 
vulnerable  elements  in  the  computer  subsystem  to 
temperature  are  the  Main  and  Bulk  Memories.  Sometimes 
extra  cooling  for  these  devices  may  permit  the  rest 
of  the  system  to  operate  at  higher  temperatures  and 
over  wider  variations. 

While  it  is  the  high  temperatures  that  have  an  adverse 
effect  on  the  computer  subsystem  it  is  the  low  humidity 
that  can  cause  an  unfavorable  operating  environment. 
High  humidity,  above  85%  R.H.,  may  cause  some  harmful 
effects  to  such  media  as  card  decks  or  magnetic  tapes, 
but  these  are  not  normally  part  of  the  real-time  oper- 
ating system.  As  long  as  there  is  not  precipitation 
of  water  vapor,  high  humidity  is  not  essentially 
detrimental  to  the  computer.  However,  low  humidity 
below  20%  R.H.,  may  permit  static  discharges  and 
cause  erroneous  operation  within  the  Control  Center. 
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The  relative  humidity  should  be  kept  between  25$  and 
80$  to  insure  minimum  unfavorable  effect. 

In  order  to  control  the  temperature  and  humidity  it  is 
necessary  that  the  Control  Center  have  an  adequate 
air  conditioning  system  that  is  reliable.  The  computer 
subsystem  usually  requires  from  15KVA  to  i+OKVA  of 
power  depending  on  the  size  of  the  equipment.  In 
turn,  this  may  represent  between  25$  and  i*5$  of  the 
total  power  requirements  for  the  Control  Center.  It 
can  readily  be  seen  that  a failure  within  the  air 
conditioning  system  may  very  well  cause  the  ECC 
temperature  to  rise  to  a dangerous  level  due  to  the 
self  heat  of  the  equipment.  While  the  total  size  of 
the  air  conditioning  system  may  depend  on  many  factors 
outside  the  sphere  of  the  computer  subsystem,  such  as 
local  climate,  building  structure , location,  etc., 
100,000  to  500,000  BTU/hr.  may  be  needed  for  the 
equipment  at  the  ECC. 

The  primary  input  power  to  the  computer  subsystem  can 
tolerate  normal  variations.  The  supply  line  voltage 
may  vary  as  much  as  +10%  while  the  line  frequency  may 
swing  as  much  as  0.5  to  1.5  Hz.  However,  voltage 
transients  or  loss  of  power  may  be  deleterious  to  the 
equipment.  The  CPU  has  usually  a very  sensitive  power 
failure  detector  because  it  must  be  able  to  initiate 
an  orderly  shutdown  in  the  computer  subsystem.  It 
detects  loss  of  power  within  a few  milliseconds  in 
order  to  insure  that  the  levels  of  the  internal  power 
supplies  in  the  computer  subsystem  are  capable  of 
performing  properly  before  shutdown  is  completed. 

Though  when  power  is  restored  the  computer  will  re- 
cover in  an  orderly  manner,  there  is  with  every  power 
failure  a loss  of  information  and  control.  The  cycling 
on  and  off  of  the  computer  subsystem  may  also  be  a major 
contributor  to  equipment  malfunctions.  In  addition , high 
frequency  transients  on  the  line  that  do  not  affect 
the  power  failure  detector  may  affect  the  system 
performance  by  being  transmitted  into  the  logic  and 
causing  erroneous  operation. 

To  overcome  all  these  difficulties  an  Uninterruptable 
Power  System  (UPS)  is  recommended.  The  UPS  may  consist 
of  an  inverter,  battery  and  battery  charger,  where 
the  inverter  converts  the  dc  of  the  battery  to  the  ac 
supply  voltage  for  the  equipment  and  the  battery 
charger  keeps  the  battery  at  proper  operating  level. 

The  UPS  may  be  backed  up  by  the  supply  line  or  it  may 
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be  backed  up  by  the  line . The  UPS  obviously  must  be 
capable  of  supplying  all  the  power  needed  for  the 
equipment  at  the  ECC . There  are  many  configurations 
that  can  do  this,  varying  from  one  UPS  carrying  the 
whole  load  to  two  or  even  three  UPS  sharing  the  load. 

b . Availability 

In  order  to  achieve  a high  availability  of  the  equip- 
ment at  the  ECC,  not  only  must  the  environment  and 
primary  input  be  proper,  but  also  the  equipment 
configuration  must  be  enhanced.  Availability  of 
hardware  is  calculated  as  follows: 

Availability  = Runtime 

Runtime  + Downtime 


Where:  Runtime  is  anytime  during  which  the  hardware 

is  considered  operating,  and; 

Downtime  is  anytime  during  which  the  hardware 
does  not  perform  its  required  functions 

The  real-time  components  of  the  computer  subsystem 
that  perform  the  critical  operation  have  an  availa- 
bility that  is  tha  product  of  the  availability  of 
each  component.  This  includes  the  CPU,  Main  Memory, 
Bulk  Memory  and  I/O  equipment.  The  availability  of 
such  a group  of  elements  may  be  from  99*3%  to  99*7%* 

It  should  be  noted  that  the  calculated  availability 
is  based  upon  average  values  that  may  occur  over  a 
long  period  of  time  and  thus  there  may  be  a wide 
variation  for  a short  period.  To  achieve  an  avail- 
ability of  99-8 1 the  downtime  should  be  less  than  14- 
hours  over  a 2000  hours  period  (3  months,  approximate- 
ly). This  may  require  a calculated  value  of  availa- 
bility of  99*8 %.  By  means  of  redundant  systems  in 
which  one  computer  subsystem  is  on-line  and  another 
is  available  as  back  up,  the  real-time  group  cal- 
culated availability  can  be  enhanced  to  over  99*99 %• 

The  parameters  used  for  calculating  the  availability 
are  based  on  the  Mean-Time-Between- Failures  (MTBF) 
and  the  Mean  Time  to  Repair  (MTTR)  of  each  of  the 
components  of  the  computer  subsystem.  This  data  may 
be  derived  from  a number  of  sources  which  include: 

° Estimations  based  upon  experience 
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o Comparison  to  previous  similar  equipment  with 
known  MTBF  and  MTTR 

0 Counting  the  number  of  active  groups  (transistors, 
integrated  circuits)  with  a known  MTBF 

° Counting  the  number  of  each  component  part  types 
(resistors,  connectors,  etc.)  with  a known  MTBF 

° Calculating  the  failure  rate  of  each  component 
part,  by  the  stress  analysis  method  according  to 
U.S.  Military  procedure  (MIL-HDBK-217  and  MIL- 
STD-756) . 

In  all  these  reliability  prediction  methods,  only  the 
hardware  is  taken  into  account.  The  overall  control 
system  availability  is  also  influenced  by  the  relia- 
bility of  the  software  programs.  However,  software 
is  not  subject  to  the  same  probabilities  of  failure 
that  are  common  to  hardware.  Software,  once  debugged 
and  tested  is  not  expected  to  fail  with  use.  This  is 
not  to  say  that  software  is  not  without  failures.  In 
fact,  many  if  not  most,  causes  for  the  unavailability 
of  the  control  system  during  startup  are  due  to 
errors  in  the  software. 

Every  control  system  has  its  own  particular  require- 
ments which  necessitates  the  development  of  some  new 
software  of  the  modification  of  previously  written 
software.  These  new  or  modified  software  programs 
cannot  be  thoroughly  tested  and  debugged  under  all 
circumstances  until  used  in  the  actual  system.  A few 
problems  should  be  expected  during  startup.  These 
problems  can  be  kept  to  a minimum  if  field  proved 
software  is  used  as  a basis  for  creating  the  new  or 
modified  programs  by  a well  experienced  supplier. 

After  startup  the  availability  of  control  system 
should  be  found  to  be  very  satisfactory.. 

Beside  increasing  the  availability,  a redundant 
configuration  that  is  symmetrical  also  supplies  two 
other  important  functions. . The  backup  system  can 
be  in  use  performing  background  function  thus  relieving 
the  on-line  system  of  some  of  its  load.  It  should  be 
remembered  that  the  on-line  system  can  do  any 
function,  including  background. 
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Another  important  function  of  the  symmetrical  redun- 
dant system  configuration  is  the  checking  out  of  any 
additions,  modifications  or  deletions  to  the  system. 
This  may  be  done  off-line  on  the  back-up  computer 
before  they  are  incorporated  into  the  operating 
system.  This  is  true  for  both  software  as  well  as 
hardware.  It  gives  a high  degree  of  assurance  that 
when  the  change  is  put  on-line  that  it  will  perform 
satisfactorily. 

11.  System  Software 

Perhaps  the  least  discussed  element  of  the  control  system 
and  the  element  least  understood  by  the  purchaser  of 
control  systems  is  the  system  software.  Yet  the  respon- 
siveness and  ultimate  capacity  of  the  system  are  directly 
related  to  the  efficiency  of  the  operating  system,  and 
the  cost  of  system  maintenance  and  expansion  is  a function 
of  the  software  support  facilities  provided.  The  function 
of  the  operating  system  Is  the  efficient  allocation  of 
system  resources  in  a multi-programming,  real-time 
environment.  The  support  provides  the  programming  tools 
for  hardware  and  software  maintenance  and  system  expan- 
sion . 

It  is  desirable  for  the  operating  system  to  be  specific-, 
ally  designed  for  real-time  process  control  and  monitoring. 
Very  often  operating  systems  labeled  as  real-time  are  in 
actuality  general  purpose  or  time-share  executives  that 
have  been  augmented  for  real-time  operation.  Because  they 
were  not  designed  specifically  for  real-time,  such  operat- 
ing systems  may  be  missing  certain  real-time  features  or 
can  require  excess  overhead  in  performing  real-time 
functions . 

This  portion  of  the  bulletin  is  presented  to  acquaint  the 
reader  with  the  functions  of  real-time  system  software 
and  the  desirable  features  to  be  specified  when  purchasing 
a system.  The  importance  of  system  software  should  not 
be  underestimated.  Undoubtedly,  more  development  cost  is 
behind  the  system  software  thdn  any  other  element  of  any 
control  center.  The  high  cost  of  computer  hardware  is  in 
part  due  to  the  "free"  system  software  that  comes  with  it. 

a.  Operating  System 

Within  the  multi-task,  real-time  environment,  the 
operating  system's  function  is  the  orderly  and  effi- 
cient allocation  of  central  processor  unit  time, 
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main  memory  storage,  auxiliary  memory  transfers,  and 
input/output  facilities.  The  operating  system  program 
fits  within  the  computer's  interrupt  and  priority 
structure . 

While  the  efficiency  and  capability  of  the  operating 
system  as  discussed  in  the  following  paragraphs  is  of 
obvious  importance,  the  inclusion  of  unneeded  functions 
can  be  costly.  The  operating  system  itself  requires 
system  resources  - including  typically  UOK  to  100K 
bytes  of  core  and  5%  to  25%  of  the  CPU  time.  Thus, 
the  goal  is  to  maximize  the  operating  system's 
performance  while  minimizing  its  own  use  of  resources. 
Include  the  needed  real-time  features  discussed 
below,  but  do  not  generate  unnecessary  functions 
into  your  system. 

(l)  The  Executive 


The  executive  is  the  operating  system  program 
responsible  for  scheduling  CPU  control  and  over- 
all resource  allocation. 

The  control  flow  is  based  on  the  priority 
structure.  The  calling  of  the  executive  through 
its  interrupt  signifies  an  impending  change 
in  system  environment.  Typically,  the  executive 
is  called  when  a task  (free  standing  program) 
relinquishes  CPU  control  (e.g.,  task  has  completed, 
has  initiated  an  I/O,  has  been  aborted,  etc.), 
when  I/O  is  completed  for  which  a task  is  waiting, 
or  when  a request  for  execution  has  been  made. 

The  executive  selects  the  highest  priority 
program  requesting  activation  and  for  which  re- 
quired resources  are  available,  allocates  the 
required  resources,  and  grants  CPU  control  to 
the  task. 

Requests  for  execution  are  put  into  effect  by  (l) 
interrupts,  (2)  calls  by  other  tasks,  (3)  calls 
by  the  periodic  scheduler,  and  (U)  computer 
operator  command.  When  the  executive  activates  a 
task,  it  first  locates  where  the  task  is  stored, 
allocates  the  required  peripherals  and  files  as 
defined  by  the  task  definition  data,  loads  the  task 
into  main  memory  (assuming  the  task  is  not  a re- 
sident program  in  memory) , and  grants  it  control. 

An  important  feature  (often  called  look  down  or 
look  behind)  is  the  capability  of  the  executive  to 
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activate  a lower  priority  task  when  any  of  the 
resources  required  by  the  highest  priority  task 
are  being  utilized  elsewhere  and  thus  temporarily 
not  available. 

Thus,  on  a priority  basis,  the  executive  controls 
allocation  of  the  resource  - CPU  time.  Similarly, 
during  task  activation,  the  executive  also  con- 
trols allocation  of  other  resources  - peripherals, 
bulk  memory  files,  and  main  memory.  Assignment  of 
peripherals  and  bulk  memory  files  may  be  static 
or  dynamic  and  may  be  .on  a shared  or  non-sharable 
basis.  However,  most  important  is  the  allocation 
of  main  memory,  for  it  has  the  greatest  impact  on 
the  system  workload  capability. 

Tasks  are  either  main  memory  resident  or  bulk 
resident.  The  bulk  resident  tasks  execute  in  the 
overlay  area.  The  allocation  of  overlay  is  either 
dynamic  or  based  on  a fixed  map.  Dynamic 
allocation  methods  include: 

° Software  relocation  based  on  modification  of 
instruction  addresses  during  the  loading 
of  the  task 

° Hardware  relocation  based  on  the  hardware 
addition  of  a base  register 

° Memory  mapping  where  a task  is  divided  into 
minimum  - size  increments,  usually  called 
pages,  and  scattered  about  main  memory 
wherever  available  space  exists.  Hardware 
registers  keep  track  of  the  physical  loca- 
tion of  the  pages 

The  features  of  a Real-Time  operating  system  are; 

° Task  queuing  based  on  software  priority 
levels 

° Preemption  of  low  priority  tasks  for  higher 
priority  tasks 

° Look  behind 

° Roll  in /roll  out 

° Program  non -interrupt able  status 
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Automatic  scheduling  of  periodic  tasks 

° Overlay  of  program  segments 

° Inter-task  communications  to  allow  sharing 
of  data  and  logic 

° Task  requesting  execution  of  another  task 
with  facility  to  pass  parameters 

° Real  memory  allocation  providing  for  common 
data  area,  resident  tasks,  non-rollable  tasks, 
and  Tollable  tasks 

° Foreground/background  capability 

° I/O  control  system  with  queuing  mechanism 
for  optimization  of  multiple  I/O  requests 

° Threaded  I/O  queues  per  I/O  channel  allowing 
multiple  requests  for  the  same  device  to  be 
held  on  priority  basis 

° Minimum  latency  algorithm  for  disk  transfers 

° Software  interaction  through  task  names, 
data  names  and  operational  labels  rather 
than  physical  addresses 

° Automated  SYSGEN  facilities 

0 System  performance  monitoring 

In  each  dynamic  allocation  case,  the  executive 
searches  main  memory  for  available  space.  The  key 
feature  in  either  the  dynamic  or  the  fixed  case 
is  roll  in/roll  out  (also  called  task  checkpointing )- 
the  capability  to  temporarily  transfer  an  active 
lower  priority  task  to  bulk  memory  (to  a roll- 
out area)  when  a higher  priority  task  requires 
execution  and  sufficient  unused  space  is  not 
available . 

Which  is  preferable  - fixed  map  or  one  of  the 
dynamic  methods?  Today,  most  large  control  centers 
are  being  installed  with  dynamic  allocation.  Fix- 
ed map  is  being  employed  mainly  on  small  systems. 

The  fixed  map  must  be  initially  laid  out  with  the 
ultimate  system  in  mind.  Such  consideration 
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minimizes  the  programmer  effort  to  map  each  new 
task  added  as  the  system  grows . Dynamic  methods 
eliminate  the  need  to  map  the  overlay.  Of  course, 
the  most  important  consideration  is  efficiency; 
that  is,  minimum  bulk  traffic,  minimum  bulk  wait, 
minimum  CPU  overhead,  and  as  a result  maximum 
ultimate  capacity.  At  first  glance,  one  might 
select  the  fixed  map,  which  can  be  tuned  to 
improve  performance,  as  the  most  efficient. 
However,  the  task  execution  requirements  in  large 
systems  are  very  dynamic.  Thus,  tuning  that  is 
optimal  for  one  period  of  activity  may  not  be 
optimal  for  the  next  period.  Dynamic  methods  are 
created  for  changing  environments  and  could 
potentially  be  more  efficient.  However,  to  date, 
no  general  method  is  by  definition  superior  to 
another.  Analysis  of  the  specific  approach  and 
features,  performance  of  benchmarks  modeling  the 
expected  environment,  and  measurements  from 
existing  similar  installations  can  all  be  used 
to  help  anticipate  the  performance  of  a given 
memory  -allocation  technique  for  a given  planned 
control  system. 

A multi-task,  real-time  environment  also  necessi- 
tates inter-task  communication  facilities.  Typical 
methods  include  the  passing  of  parameters  when 
one  task  calls  another  and  the  setting  of  in- 
dicator bits  called  flags.  A common,  global  data 
base  not  only  contains  system  data,  but  can  also 
be  used  as  an  inter-task  mailbox.  Access  to 
common  data  should  be  symbolic  and  not  require 
the  task's  knowledge  of  a specific  physical 
address.  Such  facilities  become  even  more  critical 
in  multiple  processor  configurations. 

(2)  Periodic  Scheduler 


The  periodic  scheduler  works  in  conjunction  with 
the  executive  to  automatically  activate  tasks 
based  on  time  of  day  or  elapsed  time.  While 
the  periodic  scheduler  may  be  provided  by  the 
computer  supplier,  it  is  often  an  enhancement 
created  by  the  system  vendor.  (Note  l)  The  user 
places  a periodic  task  on  the  periodic  queue  and 
defines  its  start  time  and  execution  interval. 
Programs  may  be  periodic  or  single  shot.  The 
periodic  scheduler  is  assigned  to  an  external 
interrupt  driven  by  a real-time  clock.  Each  time 
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the  interrupt  is  triggered  the  periodic  scheduler 
checks  the  periodic  queue  and  places  the  appro- 
priate tasks  on  the  executive's  queue.  Resolution 
of  a few  milliseconds  should  be  provided  with 
intervals  ranging  from  one  second  to  2b  hours . 
Scheduler  maintenance  facilities  should  include 
capability  to  activate,  deactivate,  add,  delete, 
and  change  parameters  of  periodic  tasks. 

Note  1 : The  system  supplier  usually  supplies  the 

computer  as  an  element  of  his  offering.  The  com- 
puter supplier,  who  supplies  the  computer  to  the 
system  supplier,  often  may  be  a different  company 
or  a different  group  within  the  same  company  as 
the  system  supplier . 

(3)  Input /Output  Processing 

Input/output  is  accomplished  either  by  direct  I/O 
or  by  an  I/O  processing  program.  The  facilities 
of  the  I/O  processor  are  used  in  all  cases  except 
if  a situation  exists  where  the  I/O  transfer 
cannot  afford  the  overhead  of  the  I/O  processor. 
Thus,  direct  I/O  may  be  more  typically  used  for 
infrequent  and  short  transfers. 

I/O  processing  involves  both  the  general  I/O  pro- 
cessor and  device  - oriented  I/O  servers.  The  I/O 
server  drives  the  device  controller  through  which 
data  is  sent  and  received  between  main  memory  and 
the  device . Server  features  should  include 
priority  I/O  buffering,  performance  of  error 
checking,  and  initiation  of  retries.  The  general 
I/O  processor  should  be  a device  independent  - 
operational  labels  used  rather  than  devices  names 
or  addresses.  Processor  features  should  include 
I/O  queuing  with  priority  execution,  format  control, 
and  code  conversion. 

Another  desirable  I/O  feature  is  called  "spooling". 
Spooling  is  the  bulk  buffering  of  I/O  to  and  from 
a peripheral  device,  usually  a low  speed  device 
such  as  a card  reader  or  a line  printer.  Bulk 
buffering  permits  a task  to  read  or  write  at  a high 
rate  to  a disc  rather  than  a low  rate  to  a card 
reader  or  line  printer.  Also  when  the  transfer  is 
made  to  or  from  the  low  speed  device,  it  is  made 
at  the  maximum  speed  of  the  device  rather  than  at 
the  intervals  at  which  the  task  is  performing  reads, 
and  writes. 


11-32 


( k)  File  Management 


File  management  software  maintains  the  tape  and 
disc  storage  of  programs  and  data  and  the  directo- 
ries defining  such  .storage.  Routines  should  he 
provided  to  allow  creation  and  deletion  of  files 
and  sequential  and  random  file  access. 

These  facilities  also  allow  programs  to  request 
data  values  or  tables  or  to  call  programs  by  name 
without  having  to  know  specific  addresses.  Data 
for  energy  control  applications  may  be  stored  in 
tables  rather  than  records  and  files.  Tables  allow 
the  data  base  to  be  represented  closer  to  the 
way  the  user  understands  and  organizes  his  data, 
allowing  for  easier  comprehension  and  expansion  by 
the  user.  In  this  case  file  facilities  provided 
by  the  computer  supplier  can  be  adapted  by  the 
system  supplier  to  automate  program  and  data 
storage,  access,  and  modification.  System 
supplier  provided  data  base  generation  programs 
(described  later  in  this  section)  should  be 
designed  to  work  with  file  management  software  so 
that  a program’s  reference  to  data  by  name  is 
automatically  translated  to  a file  name,  offset 
into  the  file,  and  number  of  bytes  required. 

( 5 ) System  Generation  (SYSGEN) 

SYSGEN  software  permits  the  tailoring  of  the 
software  system  to  reflect  the  hardware  and 
software  requirements  of  the  user.  Facilities 
provide  for  the  selection  of  operating  system 
features,  definition  of  directories,  files,  and 
libraries,  assignment  of  interrupts  and  devices, 
and  establishment  of  resource  parameters  such  as 
the  amount  of  main  memory . 

Full  sysgen,  short  sysgen,  and  reload  facilities 
should  be  provided.  Full  sysgen  is  the  initial 
SYSGEN  performed  by  the  system  supplier.  Short 
sysgen  facilities,  which  are  of  particular 
importance  to  the  user,  allow  rapid  modification 
of  the  system  using  the  previously  generated 
system  as  a base.  Such  modifications  would  include 
the  addition  of  a peripheral  or  the  expansion 
of  a file  size.  Short  sysgen  facilities  are  aimed 
at  minimizing  user  effort  and  computer  down-time. 
Finally,  reload  is  the  reactivation  of  the  system 
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using  the  system  image  stored  on  bulk.  Reload  is 
an  integral  part  of  automatic  start-up  and  fail- 
over described  later  in  this  section. 

(6)  Software  Accounting 

A software  accounting  program  monitors  system 
load.  Accounting  software  is  often  a system 
supplier  addition.  It  allows  forecasting  the 
effect  of  system  expansion  and  analysis  of  ways 
to  reduce  CPU  overhead  and  I/O  wait  time.  Typical 
data  measured  and  displayed  includes  CPU  idle 
time,  number  of  roll  outs,  number  and  average 
lengths  of  I/O  requests,  and  average  and  peak 
load  on  the  system  task  queue.  This  level  of 
accounting  activity  produces  negligible  CPU 
overhead.  The  software  facilities  described  in 
the  above  paragraphs  are  the  major  elements  of 
the  operating  system  and  related  software. 

b . Support  Software 

The  support  software  provides  facilities  to  maintain 
and  expand  the  system.  Facilities  for  the  addition, 
modification  and  deletion  of  application  programs 
are  typically  created  by  the  computer  supplier  and 
provided  through  a background  monitor  package.  Cap- 
ability to  update  the  data  base  and  CRT  displays 
is  provided  by  the  system  supplier  through  generation 
programs  that,  depending  on  the  supplier,  may  be 
either  foreground  or  background  programs. 

(l)  Foreground/Background 

Background  is  by  definition  either  the  lowest 
priority  level  in  the  system  of  a limited  class 
of  programs  and  is  interruptable  and  rollable  by 
higher  priority  tasks.  Background  programs  are 
associated  with  support  activities.  Foreground 
programs  are  all  on-line,  periodic  or  demand 
tasks  essential  for  system  operation.  Foreground 
programs  perform  the  daily  real-time  and  operator- 
requested  operations.  The  foreground  programs 
should  be  protected  (protection  from  modification 
or  destruction  of  instructions  or  data)  through 
hardware,  software,  or  procedural  methods  from 
programs  executing  in  background. 


II-3b 


(2)  Batch  Processing 


Background  programs , being  the  lowest  priority 
or  a limited  class,  execute  in  a batch  mode.  This 
background  job  stream  is  initiated  by  a programmer 
through  a programmer's  terminal,  typically  a key- 
board printer  or  compatible  CRT.  The  programmer 
interacts  with  the  background  monitor  through  a 
controversial  job  control  language.  Jobs  and  job 
control  instructions  are  input  from  cards  or  tape; 
source  and  object  files  are  maintained  on  disc 
and  tape;  and  output  is  to  the  line  printer, 
magnetic  tape,  disk,  or  other  output  device  such 
as  an  X-Y  plotter.  Using  these  peripherals  and 
the  facilities  of  the  background  monitor,  the 
programmer  can  assemble,  compile,  load,  test, 
debug,  integrate  and  execute  programs. 

(3)  Assemblers 

The  assembler  converts  assembly  language  source 
code  into  object  code  which  serves  as  an  input 
module  to  a link  and  load  program.  Important 
assembler  features  include: 

0 Macro  definition  - capability  for  user  to 
write  his  own  assembler  source  instructions 
to  define  frequently  used  operations 

0 Conditional  assembly  - capability  to  mark 
certain  source  instructions  and  then  to 
assemble  either  with  or  without  those  in- 
structions. Thus,  for  example,  code  useful 
in  test  and  debug  can  be  assembled  in  for 
testing,  but  out  for  final  integration 

User  output  should  include: 

0 Absolute  or  relocatable  object  code 

0 Source  and  object  listings 

0 Error  messages  and  diagnostic  data 

( U)  Compilers 

The  compiler  converts  high  level  language  source 
code  into  object  code  which  serves  an  input  mod- 
ule to  a link  and  load  program.  While  seme  use 
has  been  made  of  COBOL  and  ALGOL,  FORTRAN  TV  is 
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by  far  the  most  common  high  level,  language.  The 
FORTRAN  IV  should  be  compatible  with  ANSI  X3.9 
1966  specif ications .Furthermore,  the  following 
real-time  extensions  are  of  value: 

0 Bit,  byte,  half  word,  word,  and  double  work 
manipulation 

0 Interaction  with  real-time  data  base 

0 Inter-program  communication  and  control  flow 

0 Multi-dimensional  arrays 

0 In-line  assembly  language  and  assembly 
language  subroutines 

0 Conditional  compilation 

0 Capability  to  call  executive  services 

More  and  more,  FORTRAN  is  being  used  for  all  but 
the  most  time  critical  application  functions  such 
as  the  interrupt  driven  routines,  the  routines 
related  directly  to  hardware,  and  those  requiring 
a considerable  amount  of  tight  bit  and  byte  manip- 
ulation. As  a result  of  this  extensive  use  of 
FORTRAN,  the  compiler's  capabilty  to  optimize  code 
has  become  very  valuable.  The  compiler  should  be 
multiple-pass  with  code  optimization,  preferably 
block  or  global,  aimed  primarily  at  a reduction 
in  run  time,  but  also  secondarily  at  a reduction 
in  required  main  memory  storage. 

As  with  the  assembler,  comprehensive  error  and 
diagnostic  messages  are  useful. 

( 5)  Utilities 

While  the  term  utilities  is  sometimes  used  to 
cover  all  system  support  software,  it  will  be 
used  here  to  cover  link  and  load,  test  and  debug, 
integration,  and  editing  facilities. 

The  link  and  load  facility,  sometimes  called  link 
editor  or  just  loader,  is  used  by  the  programmer 
to  convert  defined  object  modules  into  an  exe- 
cutable load  module.  The  facility  should  include 
the  capability  to  link  together  individual  object 
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modules  -which  consist  of  one  or  more  programs 
that  have  been  compiled  and/or  assembled.  During 
the  link  and  load  process,  data  definitions  exter- 
nal to  the  individual  object  modules  are  refer- 
enced to  one  another  and  to  the  system's  common 
data  base.  Once  tested  and  integrated,  the  exe- 
cutable load  module  can  become  a task  in  the 
real-time  system. 

Thus,  test  and  debug  facilities  are  required  so 
that  the  user  can  be  sure  the  program  is  function- 
ing properly  before  it  is  integrated.  Facilities 
should  allow  the  test  and  debugging  of  programs 
in  a manner  that  will  not  jeopardize  real-time 
operation.  In  practice,  background  work  including 
test  and  debug  is  usually  performed  on  the  back-up 
computer  in  a dual  computer  system.  This  practice 
not  only  insures  the  safety  of  the  real-time 
operation,  but  also  means  quick  turnaround  since 
background  in  the  back  up  need  not  vie  with  the 
myriad  of  foreground  programs  for  CPU  time.  The 
user  should  be  able  to  accomplish  testing  using 
both  test  data  and  real  system  data.  Capability 
to  use  real  system  data  in  a mirror-image  back-up 
system  permits  testing  in  a simulated  real-time 
environment.  Important  debug  capabilities  include 
trace,  snapshot,  and  memory  and  register  alter 
and  dump. 

Once  the  program  is  tested,  the  user  is  ready  to 
add  to  the  system,  perhaps  as  a real-time  program 
to  run  periodically  or  maybe  a study  program  to 
be  called  on  demand.  The  program  may  be  a new 
function  or  a replacement  for  an  existing  program. 
Integration  facilities  allow  the  user  to  define 
the  task  to  the  operating  system  - to  allocate 
bulk  storage  and  to  set  up  or  modify  task  defini- 
tion tables  in  the  executive. 

To  maintain  source  and  object  modules,  the  user  is 
provided  with  editing  facilities.  Source  editors 
are  often  termed  source  update  programs;  while 
object  editors  are  often  called  library  update 
programs  or  library  editors.  Source  is  usually 
stored  on  tapes;  while  object  is  usually  stored 
in  bulk  memory.  Facilities  should  be  included 
to  add,  delete,  or  modify  specific  line  or  lines 
of  source  code  via  record  or  sequence  number  and 
to  obtain  an  updated  listing.  Similar  facilities 
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should  be  provided  for  object  modules  where  these 
modules  include  system  libraries  such  as  math  and 
scientific  subroutine  libraries.  Capability  should 
be  included  to  store  the  modified  code  separately 
from  the  original  so  that  the  original  could  be 
retained  as  long  as  desired. 

( 6 ) Display  and  Data  Base  Generation 

The  organization  of  displays  and  the  data  base  is 
rather  unique  to  the  electric  power  control  ap- 
plication, and  for  this  reason  software  for 
maintenance  and  expansion  of  the  data  base,  dis- 
plays, and  logs  is  usually  created  by  the  system 
supplier  rather  than  the  computer  supplier.  During 
the  lifetime  of  a system,  existing  functions  and 
remote  stations  will  be  expanded  and  new  functions 
and  remote  stations  will  be  added,  thus  expanding 
the  data  base  and  number  of  displays  and  logs. 

Data  base,  display,  and  log  generation  programs 
are  absolutely  essential  to  minimize  the  program- 
ming effort  to  maintain  any  large  control  center. 
Details  on  generation  programs  are  given  in  the 
"Display  Subsystem"  portion  of  the  bulletin. 

c.  Automatic  Start-Up  and  Failover 


The  automatic  start-up  and  failover  hardware  and  soft- 
ware is  designed  to  maximize  the  availability  of  crit- 
ical system  functions  within  the  constraint  of  the 
number  of  dollars  available.  Along  with  this  primary 
goal,  a balance  must  be  achieved  between  two  secondary 
goals:  l)  minimize  loss  of  information  as  a result  of 
switching  equipment  of  systems  and  2)  minimize  the 
increase  in  CPU  and  I/O  loading  due  to  the  execution 
of  security  software.  An  important  and  sometimes 
overlooked  aspect  in  reaching  the  goal  of  maximum 
availibility  is  the  minimizing  of  failure  rate  in- 
crease due  to  failures  in  the  hardware  and  failability 
in  the  software  that  is  dedicated  to  error  detection 
and  recovery.  The  following  describes  software 
features  and  functions  related  to  failover  detection 
and  recovery.  This  software  operates  in  conjunction 
with  the  failover  hardware  and  redundant  or  backup 
equipment  described  earlier.  The  discussion  is  based 
on  the  common  symmetrical  redundant  on-line  system  - 
back  up  system. 
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(l)  Malfunction  Detection 


The  first  step  in  maximizing  availability  is  the 
detection  of  errors.  Errors  can  be  hardware  and 
software.  Hardware  errors  result  from  either 
temporary,  intermittent,  or  sustained  hardware 
failures.  Software  obviously  does  not  fail,  but 
can  contain  design  and  coding  errors.  Errors  must 
be  detected,  and  recovery  action  varying  from  re- 
tries to  failover  must  be  taken.  An  undetected 
error  can  cascade  causing  more  severe  failure  of 
the  system  and  greater  difficulty  in  isolating  the 
original  cause. 

Some  examples  of  malfunction  detection  techniques 
are  as  follows: 

° Data  transfer  error  codes  - For  example, 
parity  bits  are  typically  associated  with 
main  memory  reads  and  such  I/O  devices  as 
magnetic  tapes  and  disc.  In  these  cases, 
recovery  techniques  include  retries,  restarts, 
and  when  required,  failover 

° Interval  timers  - Peripheral  device  failure 
is  often  detected  through  the  device’s  fail- 
ure to  respond  to  a request  after  a certain 
period  of  time.  The  elapse  of  a timer  sig- 
nals the  failure  to  respond,  and  if  multiple 
retries  are  unsuccessful,  the  device  would 
be  declared  failed.  Then  depending  on  the 
device,  device  backup  or  system  failover 
could  be  initiated 

° Traps  - Errors  such  as  non-existent  memory 
access,  unimplemented  instruction,  or 
memory  protection  violations  result  in  a 
trap.  Depending  on  the  nature  of  the  fault, 
the  trap  routine  could  initiate  a retry,  a 
restart,  or  a failover 

° Data  acquisition  error  codes  - Error  coding 
such  as  Bose-Chaudhur i is  employed  in  data 
acquisition  and  control  communications. 
Detected  code  errors  can  result  in  retries, 
backup,  or  failover,  depending  on  the  nature 
of  the  situation 
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Every  time  an  error  is  detected,  the  system  opera- 
tor should  he  alerted  via  an  error  message  display 
and  printout.  Necessary  system  status  data  should 
he  included  in  the  printout.  Printouts  are  also 
helpful  for  later  fault  location. 

Once  an  error  is  detected,  the  system  attempts  to 
recover  in  a manner  resulting  in  minimum  impact 
on  real-time  system  operations.  As  indicated  in 
the  above  examples,  a simple  retry  may  he 
attempted, or  restart  or  failover  may  he  required. 
Initialization,  restart,  and  failover  are  dis- 
cussed below. 

(2)  Initialization 

Initialization  is  the  start-up  of  the  system  using 
an  initialized  copy  of  the  data  hase.  The  stored 
initialized  copy  is  pre-defined  and  unaltered 
during'  normal  system  operation.  Initialization  is 
useful  during  factory  integration  and  test,  when  a 
clean  start  can  he  preferable  to  using  the  latest 
copy.  However,  once  the  system  is  operational, 
initialization  is  of  little  use  as  a recovery 
mechanism  because  the  initialized  copy  quickly 
becomes  outdated  and  thus  the  impact  on  the  system 
would  he  too  great . 

( 3)  System  Update 

System  Update  software  maintains  the  latest  saved 
copy  of  the  data  used  in  both  restart  and  failover. 
Restart  and  failover  may  he  initiated  either 
automatically  or  manually.  Once  initiated,  auto- 
matic and  manual  result  in  the  same  procedure. 
Periodically,  typically  one  to  five  minutes, 
certain  main  memory  redident  data  are  snap-shot 
onto  both  the  on-line  and  back  up  hulks.  Types 
of  data  saved  by  this  checkpointing  program  in- 
clude dispatcher-entered  values  such  as  overrides, 
limits,  and  schedules  plus  certain  system  status 
data  • formally , telemetered  values  need  not  he 
saved  since  they  are  reacquired  when  the  system 
restarts.  The  big  question  is  how  often  to  save 
the  data.  The  more  often  data  is  saved,  the  less 
likely  any  will  he  lost  during  failover.  However, 
more  frequent  updates  increase  CPU  and  I/O  load- 
ing, lowering  the  ultimate  capacity  to  perform  con- 
trol functions.  A typical  compromise  has  been 
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three  minutes,  but  the  answer  is  really  user  de- 
pendent, and  may  be  varied  during  the  life  of  the 
system. 

( U)  Automatic  Restart 


Automatic  restart  is  initiated  when  the  possibili- 
ty exists  that  the  on-line  system  can  recover  from 
the  detected  error  without  having  to  failover. 
Automatic  restart  obviously  has  less  impact  than 
failover  on  the  system.  The  orderly  restart  of 
the  system  typically  includes  the  following 
sequence  of  operations: 

° Interrupts  disabled 

° Executive's  queue  cleared 

° Copy  of  executive  and  checkpointed  data 
base  is  read  from  the  bulk  to  main  memory 

° Periodic  programs  added  to  queue 

° Execution  begins 

° Interrupts  armed  and  enabled 

° Operator  informed  of  new  state 

° Operator  allowed  to  enter  new  time  and  date 

( 5 ) Automatic  Failover 

Failover  to  the  back  -up  system  is  automatically 
initiated  whenever  the  master's  operation  is 
unacceptably  impaired,  such  as  the  case  if  re- 
occuring traps,  or  whenever  the  master  fails  to 
update  the  deadman  timer,  indicating  it  is  either 
dead  or  hung  up.  Failover  is  the  orderly  transfer 
of  operations  to  the  back  up  system.  Needed 
peripheral  devices,  man/machine  interface,  and 
data  acquisition  hardware  are  automatically  switch- 
ed to  the  back  -up.  An  automatic  restart  of  the 
back  up  is  performed,  and  it  then  becomes  the 
on-line  master.  The  old  master  is  placed  off-line. 
Typically,  automatic  failover  is  accomplished  in 
no  more  than  twenty  seconds. 
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The  system  operator  may  observe  a malfunction  not 
detected  by  the  software  to  determine  if  a fail-, 
over  is  required.  Manaully  initiated  failover 
must  follow  the  same  procedure. 

( 6 ) Device  Back  Up 

Automatic  back  up  of  a failed  device  is  performed 
in  order  to  retain  the  function  performed  by  the 
device.  Back  up  may  be  to  an  identical  device  or 
to  a similar  device  capable  of  performing  the 
function.  The  back  up  device  may  be  a dedicated 
back  up  for  one  or  more  operating  units,  or  it 
may  be  an  operating  device  that  would  have  to 
perform  its  own  function  plus  ,the  failed  function. 
Non  critical  devices,  such  as  X-Y  plotter,  will 
probably  have  no  back  -up. 

When  a device  fails,  the  operator  should  be  in- 
formed of  the  failure  and  the  new  back  up  device, 
if  any.  The  back  up  should  be  automatic  and  require 
no  programmer  or  operator  modifications  to  the 
system.  Multiple  levels  of  back  up  should  be 
defined  where  possible.  Of  course,  the  operator 
must  have  the  capability  to  initiate  the  transfer 
to  a back  up  when  he  detects  a problem. 

d.  Diagnostics 

Diagnostics  are  programs  used  to  locate  hardware 
failures.  Three  levels  are  usually  available: 

° On-line,  run  under  the  operating  system 

0 Off-line,  run  under  a diagnostic  executive 

° Off-line,  stand  alone 

A diagnostic  is  designed  for  a specific  device  such  as 
a specific  type  of  CRT  display  unit  or  for  a sub  unit 
such  as  the  main  memory  of  the  computer . 

(l)  On-Line  Diagnostic 

On-line  diagnostics  are  often  called  on-line 
exercisers  because  of  the  limited  testing  that 
can  be  performed  on-line.  On-line  testing 
cannot  be  permitted  to  disrupt  critical  real- 
time operations.  Thus,  at  most,  a test  pattern 
could  be  output  on  a device  such  as  one  of  many 
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redundant  CRT’s.  In  fact,  it  is  often  said  that 
the  real-time  operations  are  the  best  exerciser 
of  the  system.  Generally,  on-line  diagnostics 
are  of  very  limited  value  and  are  certainly  the 
least  important  level,  the  main  use  being  the 
periodic  testing  of  equipment  having  relatively 
low  level  of  use. 

( 2)  Off-Line  Diagnostic 

Off-line  diagnostics  are  important  tools  for  the 
maintenance  engineer.  Typically,  when  a problem 
occurs,  it  is  reported  by  the  malfunction  detec- 
tion program  or  noticed  by  the  operator.  Depend- 
ing on  the  location  of  the  problem,  either  the 
system  is  failed  over  or  the  problem  device  is 
transferred  off-line.  The  failed  component  could 
be  made  to  duplicate  the  problem  to  further 
identify  it.  A series  of  diagnostics  can  be  run 
under  the  diagnostic  executive  to  locate  the 
offending  device  or  subassembly.  The  diagnostic 
executive  also  permits  multiple  components  of 
the  computer  subsystem  to  operate  in  an  environ- 
ment which  approximates  a simplified  operating 
system.  Thus,  malfunctions  due  to  interrelated 
operations  may  be  isolated  without  the  complexity 
of  system  operation.  Then  appropriate  stand 
alone  diagnostic  is  run  to  pinpoint  the  problem. 
Pinpointing  is  done  to  the  replacement  level. 

Thus,  for  card  replacement  the  failed  card  is 
identified.  The  existence  of  a mirror  image 
system  greatly  facilitates  the  rapid  location  of 
failures.  Visible  indicators  showing  the  present 
assignment  (on-line  or  back  up)  of  every  device 
should  be  included  to  facilitate  maintenance  and 
testing. 

12.  Configuration  Selection  and  Performance  Analysis 

Configuration  selection  and  performance  analysis  are 
based  on  the  scope  of  the  application  as  defined  by  the 
user  in  his  purchase  specifications.  The  user's 
specifications  should  define  the  functions  to  be  performed, 
describe  the  desired  capabilities  and  features,  and 
should  define  both  the  initial  and  projected  ultimate 
size  of  the  application.  This  information  allows  pro- 
spective suppliers  to  size  up  the  application,  select 
what  appears  to  be  the  appropriate  configuration,  and 
analyze  its  performance  against  both  initial  and  ultimate 
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requirements.  Modifying  and  reanalyzing  as  necessary,  the 
supplier  arrives  at  his  most  appropriate  and  cost  effective 
configuration  complete  with  estimated  performance  data. 

a.  Sizing  Up  the  Application 

For  the  Vendors  to  be  able  to  size  up  the  application, 
quote  the  appropriate  configuration,  and  provide  per- 
tinent performance  estimates,  it  is  necessary  that  the 
buyer  define  the  initial  and  ultimate  scope.  The  key 
parameters  defining  the  scope  as  related  to  the 
computer  subsystem  are  detailed  in  the  following 
paragraphs . 

(1)  Data  Acquisition  Requirements 

Computer  main  and  bulk  memory  requirements  are  a 
function  of  the  number  of  remotes  scanned, and  the 
total  data  scanned.  CPU  and  I/O  loading  are  a 
function  of  the  amount  of  data  scanned  per 
second.  Thus,  the  buyer  should  specify  (for  both 
initial  and  ultimate  levels)  each  remote  to  be 
scanned,  giving  the  number  of  status  entries, 
status  entries  with  MCD  (Momentary  Change  Det- 
ection), analogs  and  accumulators,  and  the  scan 
rates . Any  special  features  such  as  Sequence 
of  Events  should  also  be  defined. 

(2)  Man/Machine  Interface  (MMl)  Requirements 

The  important  MMI  parameters  are  the  number  of 
independent  CRT  monitors  and  the  desired  update 
rate.  The  CPU  and  I/O  loading  due  to  MMI  is 
primarily  a function  of  the  number  of  CRT  updates 
per  second.  For  example,  the  buyer  may  request 
12  CRT's  initially,  plan  on  l6  ultimately,  and 
require  a four-second  update  rate.  Thus,  if  all 
CRTs  had  updating  displays  on  them,  three  updates 
per  second  would  be  required  initially  and  four 
ultimately.  The  total  number  of  displays  impacts 
bulk  storage,  but  the  Vendor  can  estimate  this 
number  based  on  the  number  of  remotes,  and  the 
application  programs  to  be  included. 

( 3)  Application  Requirements 

The  specific  functions  to  be  performed  should  be 
defined  for  they  have  major  impact  on  main  memory^ 
size  (particularly  overlay  area),  CPU  loading. 
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and  bulk  I/O  traffic.  The  required  capabilities 
and  features  should  be  specified.  For  example, 
is  the  load  flow  to  run  on  real-time  data,  study- 
data,  card  inputs,  or  all  three?  What  is  the  size 
of  the  load  flow  (number  of  lines  and  busses)? 

What  features  such  as  automatic  tap  changing  are 
required?  How  many  contingencies  are  to  be  analyzed 
per  hour?  When  such  requirements  are  not  specified, 
great  variations  in  vendor  interpretations  may 
result . 

( 1*)  Availability  Requirements 

The  most  typical  way  to  define  required  availabil- 
ity is  to  state  the  desired  level.  For  example, 
the  calculated  availability  of  all  critical  func- 
tions shall  be  99-9%  where  critical  functions  con- 
sist of  99%  of  the  data  acquisition,  automatic 
ger. . 'at  ion  control,  and  man/machine  interface. 
Another  common  approach  is  to  require  a field 
test  of  90  days  demonstrating  99-8%  availability 
of  critical  functions.  Short-term  test  require- 
ments are  almost  always  less  than  calculated 
values  - expected  performance  over  the  lifetime 
of  the  system. 

To  insure  a certain  level  of  availability,  it  may 
be  necessary  to  specify  a dual  redundant  config- 
uration for  all  critical  component s,  and  to  request 
an  availability  diagram  and  calculation.  Most 
proposed  dual  redundant  systems  will  calculate 
out  to  99-9 % or  better. 

( 5 ) Loading  Requirements 

The  buyer  should  request  CPU  and  bulk  I/O  loading 
calculations  for  both  initial  and  ultimate  sizes. 
The  calculations  should  be  for  normal  average 
loading,  based  on  reasonable  user  assumptions  of 
normal  activity.  The  vendors  should  be  required 
to  detail  any  variations  from  these  assumptions. 
Unreasonable  criteria  may  substantially  increase 
the  cost  of  the  system,  bias  the  performance  of 
the  system,  or  cause  some  bidders  to  take  excep- 
tion, thus  losing  the  comparison.  The  buyer  should 
state  the  range  of  loading  he  is  looking  for. 

While  individual  requirements  will  vary,  depending 
on  the  number  of  functions  the  user  plans  to  add 
to  the  system  during  its  lifetime, and  the  un- 
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certainty  of  the  ultimate  scope,  typical  figures 
are  U0%  to  50%  CPU  load  initial  and  60%  to  70% 

CPU  load  ultimate.  For  each  buyer  it  is  a case 
of  determining  the  appropriate  balance  betveen 

1)  system  response  and  expansion  capability  and 

2)  dollars  to  be  spent. 

(6)  Expansion  Requirements 

Spare  main  and  bulk  memory  are  major  expansion 
parameters  of  the  computer  subsystem.  Certainly, 
sufficient  main  and  bulk  memory  should  be 
supplied  to  meet  the  ultimate  scope  of  the 
application.  Typically  however,  for  the  user's 
own  use,  and  as  a margin  of  safety,  at  least  10% 
spare  main  and  25%  spare  bulk  (10%  and  25%  above 
initial  requirements)  should  be  requested  for 
the  initial  system,  and  field  expansion  should 
allow  for  at  least  25%  spare  main  and  50%  bulk 
over  the  defined  ultimate. 

( 7 ) Background  Usage  . 

In  order  to  have  proposed  the  appropriate  types 
and  numbers  of  programmer  I/O  terminals  and  I/O 
equipment,  the  buyer  should  either  specify  the 
types  and  numbers  desired  or  describe  the 
expected  level  of  program  development,  system 
maintenance,  and  expansion  activity. 

(8)  Special  Features 

The  final  major  items  to  define  are  the  special 
features.  For  example,  is  this  system  part  of  a 
hierarchial  structure  such  that  communications 
with  other  computers  are  required?  What  is  the 
nature  of  these  communications?  What  is  existing 
equipment  to  be  interfaced  with? 

b . Computer  System  Selection 

Based  on  a specification  that  scopes  the  application, 
a system  supplier  is  able  to  select  the  computer 
having  the  necessary  hardware  and  software  capabili- 
ties and  features,  configure  the  computers  to  pro- 
vide the  required  CPU  power  and  availability,  and 
select  the  types  and  numbers  of  peripherals  to 
provide  specified  functions  at  a specified  level  of 
availability . 
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(l)  Computer 


Most  system  suppliers  have  a number  of  computers 
or  a number  of  models  of  the  same  computer  from 
which  to  select.  Typical  variations  within  the 
models  include  main  memory  speed,  memory  size 
limit,  instruction  speeds,  I/O  bandwidth , floating 
point  implementation,  system  software  features, 
and  supported  peripherals.  Different  computers  vary 
by  these  factors,  and  many  more,  including  word  size. 

The  selection  of  the  computer  is  not  really  a 
separate  step  from  the  selection  of  the  config- 
uration, because  the  resulting  configuration  may 
consist  of  a number  of  different  computers  or 
computer  models . 

(2)  Configurations 

The  dual  redundant  system  is  the  most  common 
configuration.  In  this  case  each  side  consists 
of  a single  computer.  This  single  computer  must 
contain  all  the  desired  real-  time  features  and 
perform  all  the  functions  specified  for  at  least 
the  initial  scope.  In  another  type,  each  side 
consists  of  multiple  computers:  one  acting  as  the 
primary  machine  containing  all  the  necessary 
real  time  features,  doing  a portion  of  the  re- 
quired workload,  and  scheduling  the  workload  for 
the  others,  where  each  of  the  others  acts  as  a 
processor  dedicated  to  certain  pre-defined  tasks. 
Such  dedicated  tasks  include  data  acquisition, 
man/machine  interface,  and  large  computational 
applications.  Dedicated  processors  can  be  cross- 
strapped  to  work  with  either  primary  machine. 
Cross-strapping  can  improve  availability,  but  can 
only  be  employed  where  interfaces  between  the 
machines  are  such  that  a failure  in  the  one  system 
cannot  cascade  into  the  other. 

A number  of  earlier  installations  consisted  of  a 
single  computer  with  analog  backup.  Such  an  ap-* 
proach  minimized  initial  cash  outlay  and  provided 
a field  proven  back  up  for  the  system's  key 
function,  automatic  generation  control.  Today, 
such  an  approach  is  not  the  favored  approach  for 
a large  control  center,  because: 
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0 A backup  computer  system  has  proven  ex- 
tremely useful  for  system  maintenance  and 
expansion,  running  of  off-line  study  pro- 
grams, and  troubleshooting 

0 Digital  Computer  Control  is  field-proven 

° Computers  now  provide  critical  security 
functions  that  cannot  be  backed  up  by 
analog  equipment 

° Cost  of  the  back  up  system  is  a relatively 
small  percentage  of  the  cost  of  the  entire 
control  system 

Another  feasible  approach  would  be  a distributed 
processor  conf iguration.  In  this  type  configuration, 
there  is  no  symmetrical  back  up  system  to  the  on- 
line system.  Backup  is  achieved  by  either  having 
one  computer  be  a dedicated  backup,  or  by  having 
a degraded  backup, with  a computer  having  to  do  its 
own  function  and  the  function  of  the  failed  pro- 
cessor. Each  processor  has  its  own  set  of  tasks, 
but  none  usually  acts  as  a primary  controlling 
machine.  Interprocessor  and  intertask  communica- 
tions and  access  to  aommon  data  is  through  some 
combination  of  communications  channels,  shared 
main  memory,  and  shared  bulk  storage.  The  present 
risk  in  selecting  such  a configuration  is  that: 

° It  is  the  least  common  approach  in  electric 
power  control  applications 

° Its  performance  relies  heavily  on  the 

success  of  the  communications  and  resource- 
contention  schemes 

° It  does  not  provide  the  mirror  image  system 
that  is  so  useful  in  trouble  shooting  and 
program  testing 

° The  availability  of  the  individiial  processor 
must  be  much  higher  than  that  of  a large 
computer  that  could  handle  the  entire 
application  in  order  to  have  the  availability 
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of  the  distributed  processor  configuration 
approach,  that  of  a dual  computer  system 

0 Each  computer  must  be  uniquely  engineered 
and  SYSGENed,  unless  they  are  all  over- 
sized to  keep  them  common 

With  the  performance  of  hardware  and  cost  of 
engineering  and  programming  going  up,  this 
approach  should  not  be  attractive  in  the  near- 
term  future . 

(3)  Peripherals 

The  selection  of  peripherals  is  also  not  independ- 
ent of  the  computer  selection,  because  supported 
peripherals  may  even  vary  between  computer  models. 
The  key  factors  in  peripheral  selection  are 
overall  workload,  the  user's  plans  for  his  own 
programming  and  expansion  activities,  and  special 
applications.  The  selection  of  the  type,  number, 
and  storage  capacity  of  the  disks,  is  directly 
related  to  the  defined  workload  and  the  computer 
configuration.  The  programmer  terminal  equipment, 
the  speed  and  number  of  magnetic  tape  units  are 
directly  related  to  thfe  planned  programming  and 
system  expansion  activities.  Historical  data 
storage  requirements  may  necessitate  additional 
disk  capacity  or  magnetic  tape  units.  Special 
application  programs  may  require  an  X-Y  plotter 
or  trending  capability. 

(1+)  Given  the  options  above,  how  does  the  system 

supplier  arrive  at  his  best  solution?  Typically, 
he  will  ball  park  the  CPU  loading  required  by 
the  average  number  of  remotes  and  amount  of  data 
to  be  scanned  per  second,  the  average  number  of 
CRT's  to  be  updated  per  second,  and  the  total 
application  program  loading  - the  programs  re- 
quired, the  sizes  of  the  models,  the  frequency 
of  execution,  and  the  special  features  required. 

If  all  these  requirements  (ultimate  plus  spare) 
can  be  accomplished  by  a single  computer  (computer 
standard  to  that  supplier)  having  the  necessary 
real-time  features,  then  a majority  of  suppliers 
will  select  the  symmetrical  dual  redundant 
configuration.  This  approach  is  the  most  field- 
proven,  least  complex,  and  the  easiest  to  field 
expand  to  reach  the  ultimate  scope. 


11-1*9 


However,  there  are  two  other  possibilities.  The 
supplier  may  offer  a dual,  redundant  system  that 
meets  the  initial  requirements  and  that  can  be 
field  expanded  by  the  addition  of  dedicated  pro- 
cessors, to  form  a multiprocessor  configuration 
capable  of  meeting  the  ultimate  requirements. 

The  advantage  is  the  reduced  initial  cash  outlay 
and  shorter  initial  delivery.  The  disadvantage 
are  the  extra  cost  involved  in  field  expansions 
over  factory  implementation  of  the  entire  system, 
the  greater  interruption  and  risk  involved  in 
field  additions,  and  the  loss  of  the  added 
capability  prior  to  the  field  expansion.  Because 
of  the  above  reasons,  this  approach  has  been 
planned  more  often  than  it  has  been  accomplished. 

The  second  possibility  is  that  the  supplier  will 
quote  a multiprocessor  configuration  even  though 
he  has  a single  computer  that  could  do  the  job. 

He  may  do  this  if  he  can  achieve  significantly 
reduced  hardware  costs,  or  if  the  smaller  computers 
were  better  suited  to  the  real-time  application. 
These  advantages  must  be  weighed  against  the 
increased  risk  and  complexity  of  the  solution. 

When  the  scope  requires  multiple  computers,  the 
supplier  may  be  able  to  quote  a dual,  redundant 
multiprocessor  configuration,  if  his  computers 
are  designed  for  that  purpose.  The  function  of 
the  dedicated  processors  are  to  off-load  the 
primary  computer.  The  scope  of  the  data  acquisi- 
tion, man/machine  interface,  and  application 
computations  determines  the  number  and  capability 
of  the  dedicated  processors  and  division  tasks. 
Cross-strapping  of  redundant  processors  between 
primary  computers  is  employed  where  possible. to 
increase  availability. 

c . Validating  the  Selection 

Having  made  an  initial  selection  of  computer  subsystem 
equipment  and  configuration,  the  prospective  supplier 
should  calculate  expected  performance.  The  key 
computations  are  CPU  loading  for  each  processor  and 
I/O  channel  loading  for  each  major  channel  (within 
the  computer  subsystem,  bulk  I/O  loading  is  the  most 
critical) . In  determining  the  average  percent  CPU 
and  I/O  loadings  under  normal  conditions,  the  average 
loading  due  to  each  task  should  be  specified  and  all 
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assumptions  should  be  defined.  Average  loading  rather 
than  peak  loading  is  calculated,  because  the  peak 
load  is  always  100$,  i.e.,  the  CPU  is  either 
executing  or  idle.  Furthermore,  and  more  important, 
whenever  there  is  active  a background  task  or  low 
priority,  long  running- study,  the  CPU  will  be  100$ 
loaded  (assuming  no  other  resource  constraint  exists) 
until  the  task  is  complete.  It  will  use  all  spare 
CPU  time. 

The  supplier  must  also  define  the  information  flow 
and  insure  the  integrity  of  the  data.  Communication 
protocol  between  processors  and  peripherals  must 
be  established.  Where  common  data  is  shared  among 
processors,  contention  procedures  must  be  established. 

Availability  diagram  and  calculations  should  be  made. 
The  supplier  should  be  able  to  state  that  there  is  no 
single  known  hardware  contingency  that  could  cause 
the  complete  loss  of  any  critical  function.  The 
supplier  should  also  describe  the  precautions  taken 
to  isolate  the  on-line  system  from  the  back  up  system 
so  that  a failure  in  one  cannot  avalanche  into  the 
other . 

The  analysis  that  each  prospective  supplier  prepares 
not  only  allows  him  to  establish  his  best  computer 
offering,  but  also  helps  the  buyer  to  determine  the 
adequacy  of  the  proposed  system  and  the  relative 
comparison  to  other  proposed  systems.  The  final 
measure  of  a proposed  computer  subsystem  includes 
this  analysis  plus  other  key  considerations  such  as: 

0 How  experienced  is  the  supplier  in  providing 
such  a level  system?  What  is  the  past  experience 
of  my  company  and  other  companies  in  dealing 
with  this  supplier? 

0 How  fie Id -proven  are  the  approaches  the  supplier 
proposes? 

0 How  much  does  the  computer  subsystem  cost? 

What  provisions  for  future  expansion  have  been 
included? 

° Does  the  hardware  and  software  system  provide 
all  the  necessary  real-time  and  user  features? 
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0 Does  the  supplier  support  the  entire  offering 
with  documentation,  diagnostics,  spare  parts, 
training, and  factory  testing? 

D.  Man /Machine  Interface 

1.  Introduction 


The  Energy  Management  System  as  conceived  in  the  mind 
of  today’s  power  dispatcher  does  not  manifest  itself  as 
sophisticated  algorithms  or  a complex  hardware  configur- 
ation but  rather  as  a flexible  man/machine  interface 
subsystem.  Although  the  design  and  implementation  phase 
may  take  two  to  three  years,  the  man/machine  interface 
subsystem  will  remain  visible  and  become  the  primary  cri- 
terion for  system  acceptance  and  successful  implement- 
ation for  several  years. 

In  order  to  adequately  design  a man/machine  interface, 
the  designer  must  be  familiar  with  the  work  of  the 
dispatcher.  The  primary  objectives  of  the  man/machine 
interface  is  to  speed  and  strengthen  the  dispatcher's 
decision  making  process  and  to  alleviate  him  of  the 
routine  efforts  involved  in  monitoring  and  logging. 
Consideration  must  be  given  to  the  present  role  of  the 
dispatcher  within  the  organization.  In  addition,  if  the 
system  achieves  its  primary  objectives,  the  dispatcher 
will  have  additional  time  available  for  future  functions 
that  must  also  be  considered. 

In  considering  future  functions,  one  must  also  consider 
future  changes  within  the  organization  that  would  enlarge 
the  dispatcher's  sphere  of  operation.  Typical  of  these  are 
load  management  functions,  trouble  dispatching,  etc. 

These  future  functions  are  most  difficult  to  define  in 
specification  terms  so  that  typically  the  specification 
writer  will  indicate  the  type  of  function  and  then  al- 
locate a block  of  system  resources  to  be  used  for  all  fu- 
ture functions. 

It  is  important  to  keep  in  mind  the  differences  between 
required  functions  and  those  that  would  be  nice  to  have. 

A common  pitfall  in  many  systems  is  that  the  computer 
system  is  used  to  perform  not  only  the  essential 
functions  but  many  of  the  record  keeping  functions  that 
simply  replace  a notebook  and  telephone.  This  latter 
type  of  function  is  quite  acceptable  as  long  as  it  does 
not  detract  from  the  resources  being  utilized  to  provide 
for  the  essential  functions  of  monitoring  and  control. 
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All  electric  system  Borrowers,  while  charted  with  the 
same  responsibilities,  are  unique  in  their  procedures  and 
approach  to  the  problems.  For  that  reason,  the  man/machine 
will  be  unique  to  each  individual  company;  that  is,  the 
implementation  of  the  various  similar  techniques  will  be 
different  depending  upon  the  requirements  at  each 
company. 

All  vendors  have  a preferred  method  of  satisfying  the 
requirements  of  the  man/machine  interface,  but  it  will 
most  probably  be  modified  to  some  degree  for  each  utility. 
It  is  in  the  best  interest  of  both  the  end  user  and  the 
vendor  if  these  modifications  can  be  minimized  so  that 
basic  modules  of  the  man/machine  approach  can  be  similar 
across  many  different  projedts. 

In  designing  the  man/machine  interface  subsystem,  the 
primary  goal  should  be  to  keep  the  method  of  operator/ 
dispatcher  interface  as  simple  as  possible,  requiring 
the  minimum  number  of  actions  by  the  dispatcher.  The 
system  should  be  designed  for  the  system  dispatcher 
with  his  influence  playing  a major  part  in  the  system 
design. 

In  order  to  gain  acceptance  at  the  earliest  possible  time 
by  the  dispatcher,  an  attempt  should  be  made  to  adhere 
to  the  basic  procedure  and  methods  used  by  the  dispatcher. 
A drastic  change  in  operating  procedures  will  result  in  a 
much  harder  acceptance  period  once  the  system  has  been 
installed.  For  example,  if  the  dispatcher  has  tradition- 
ally called  substations  by  name,  and  now  he  must  number 
each  substation  and  refer  to  it  by  number,  the  system 
acceptance  period  will  be  more  difficult.  Therefore,  if 
procedures  exist  that  are  being  implemented  in  the  man/ 
machine  subsystem,  close  adherence  to  the  familiar 
procedures  should  be  maintained. 

In  addition,  specification  writers  typically  write  the 
specification  considering  the  efforts  during  the  first 
six  months  of  system  use.  An  attempt  should  be  made  to 
include  facilities  that  the  dispatcher  will  use  after 
he  becomes  quite  familiar  with  the  basic  operation  of  the 
system.  Typical  short  cuts  for  display  request  can  be 
built  into  the  system  while  normal  procedure  may  be  to 
proceed  from  a menu  to  a substation.  It  is  quite  possible 
to  provide  tools  that  will  let  the  dispatcher  move  from 
substation  to  substation  without  returning  to  the  menu 
or  the  top  level  of  display.  This  type  of  consideration 
should  be  made  assuming  that  the  dispatcher  will  become 
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quite  familiar  with  the  operation  of  the  system  within 
the  first  six  months  of  its  use. 

When  determining  the  requirements  that  are  unique  to  your 
system,  expansion  is  an  obvious  consideration.  Expansion 
of  the  man/machine  system  may  take  place  in  many  dimen- 
sions. Typical  expansion  that  affects  the  man/machine 
interface  subsystem  is  expansion  of  the  power  system 
itself.  Additional  data  points,  remote  terminals,  genera- 
ting stations,  etc.,  will  be  required  during  the  life  of 
the  system.  This  will  impact  the  number  of  displays,  the 
amount  of  data  stored,  the  mass  memory,  central  memory, 
and  access  time  for  data  retrieval.  Typical  of  the  ex- 
pansion seen  in  many  utility  companies  is  the  need  to 
disseminate  data  to  other  users  outside  the  dispatch  cen- 
ter by  use  of  high  speed  communication  circuits  to  re- 
mote CRT's.  This  function  will  again  affect  the  basic 
design  and  should  be  considered  in  the  initial  design  of 
the  system. 

The  most  important  type  of  expansion  is  that  which  is  not 
dependent  on  system  growth  but  involves  the  addition  of 
new  functions  and  capabilities  to  the  Energy  Management 
System.  This  type  of  expansion  is  the  most  difficult  to 
define.  Again,  ability  should  be  included  in  the  initial 
system  to  allow  for  both  physical  capacity  within  the 
Energy  Management  System, and  the  ability  to  link  displays 
to  data  files  created  by  such  future  applications.  This 
is  perhaps  the  most  important  and  most  frequently  over- 
looked type  of  expansion  that  will  be  required. 

As  stated  above,  the  man/machine  interface  is  unique  to 
each  user.  It  should  utilize  basic  modules  that  are  well 
supported  and  field  proven  by  the  "\fendor.  But  it  is  to  be 
tailored  for  each  user's  particular  requirements.  For 
that  reason,  it  is  desirable  to  keep  the  linkage  between 
the  system  and  the  man/machine  interface  subsystem  flex- 
ible, so  that  the  Vendor  can  implement  his  basic  system 
design  and  still  provide  a subsystem  that  is  tailored  to 
meet  the  specific  needs  of  the  user.  This  provides  an 
economic  advantage  for  the  user. 

The  load  on  the  man/machine  interface  subsystem  fluctuates 
greatly.  It  varies  over  a wide  spectrum  based  upon  the 
operator  demand  and  system  initiated  events  during  a 
period  of  time.  As  a result,  it  is  necessary  to  provide 
as  much  reserve  real-time  capacity  as  possible  within 
the  system  for  heavily  loaded  man/machine  periods.  Many 
of  the  systems  being  provided  today  isolate  this  man/ 
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machine  load  within  a specific  CPU  dedicated  to  the  sup- 
port of  man/machine  interface  requirements.  This  tech- 
nique allows  the  fixed  system  overhead  involved  in  data 
acquisition  and  communications  along  with  periodic 
functions  to  be  separated  from  the  demand  oriented  func- 
tions of  man/machine.  Where  the  fixed  functions  are  more 
easily  predicted,  the  demand  functions  will  require 
sufficient  capacity  within  the  system  so  that  the  per- 
formance criteria  will  be  adhered  to. 

The  response  of  the  man/machine  interface  subsystem  is 
most  important  during  the  heavily  loaded  periods,  specif- 
ically, during  system  disturbances  when  the  computer 
system  is  handling  a number  of  alarms,  display  requests, 
and  restorative  procedures.  It  is  the  time  period  when  a 
system,  that  is  marginal  in  its  real-time  capacity,  will 
become  loaded  down  and  be  more  of  a hindrance  to  the 
system  dispatcher  than  an  aid.  For  the  reasons  stated 
above,  it  is  most  important  to  define  and  specify  terms 
that  will  insure  the  correct  responsiveness  of  the 
system.  The  parameters  that  provide  for  this  responsive- 
ness must  be  specified  in  a quantitive  manner.  System 
timing  and  loading  parameters  should  also  be  identified 
to  the  man/machine  subsystem  and  consideration  of  ex- 
pansion should  be  included. 

2.  Data  Considerations 

The  interrelationship  of  the  data  base  and  the  display 
files  in  a real-time  system  is  critical.  The  manner  in 
which  the  data  is  stored,  arranged,  accessed,  and  dis- 
played, can  be  the  controlling  factor  in  the  viability 
of  the  real-time  system.  Typically,  the  data  for  displays 
should  be  resident  in  the  data  base;  that  is  to  say,  for 
most  types  of  information,  the  data  should  be  stored  and 
accessed  upon  request  of  a display,  rather  than  calculated 
at  display  request  time.  This  results  in  a better  response 
time . 

Assuming  that  the  data  for  display  is  resident  within  the 
data  base,  significant  differences  in  display  response 
times  will  be  obvious,  depending  upon  the  location  of  this 
data.  A typical  one-line  diagram  with  telemetered  values 
associated  with  it  stored  in  the  central  memory  resident 
data  base  will  allow  a rapid  response  time  for  this  type 
of  display.  On  the  other  hand,  data  with  a low  utiliza- 
tion factor  that  is  typically  stored  in  mass  storage, 
and  that  resides  in  several  different  data  files, or  data 
that  must  be  accessed  from  a remote  computer  upon  demand, 
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will  have  a much  slower  response  time.  When  considering 
the  responsiveness,  consideration  should  also  be  given  to 
the  location  and  type  of  data  being  required. 

The  data  flow  within  the  man/machine  subsystem  is  heavily 
dependent  upon  the  update  rate  required.  The  subsystem 
design  for  the  man/machine  lends  itself  to  the  isolation 
of  the  CRT  update  rate  from  the  overall  system  data  base 
update.  If  the  system  scan  rate  is  dependent  upon  the 
information  shown  on  the  displays,  the  communications 
time  from  the  remote  terminal  through  the  man/machine 
subsystem  is  difficult  to  predict  because  of  the  varying 
load  that  will  be  imposed  on  the  man/machine  subsystem. 

On  the  other  hand,  if  the  scanning  function  is  allowed  to 
be  free-wheeling  or  asynchronous,  and  the  man/machine 
function  updates  at  a regular  periodicity,  the  system 
load  can  easily  be  calculated  for  a particular  set  of 
system  parameters.  This  type  of  analysis  allows  the 
system  designer  to  properly  balance  the  utilization  of 
system  resources  throughout  the  system  configuration. 

3 . Techniques  Used 

Among  the  decisions  encountered  during  the  specification 
or  design  of  a man/machine  Interface  Subsystem  are  ones 
involving  the  techniques  used  for  cursor  control,  display 
selection,  alarm  philosophy,  and  device  control.  Each 
company  seems  to  devise  its  own  particular  and  unique 
approach  for  selecting  displays,  entering  data,  control- 
ling devices,  etc.  These  unique  approaches,  while  they 
allow  the  specification  writer  a creative  license, 
usually  costs  him  a great  deal  in  terms  of  unique  devel- 
opment on  the  part  of  each  Vendor.  Preferred  techniques 
proposed  by  the  Vendor  during  the  initial  investigation 
phase  should  be  allowed  for  and  encouraged  in  these  areas. 
The  specification  should  encourage  each  vendor  to  discuss 
the  preferred  techniques  for  his  system. 

a.  Cursor  Control 


Cursor  control  can  be  implemented  in  one  of  several 
methods.  The  basic  and  most  fundamental  method  is  that 
of  a group  of  cursor  control  buttons  on  the  keyboard. 
These  are  used  to  position  the  cursor  to  the  desired 
location  for  display  selection  or  data  entry  or 
device  selection.  Various  other  mechanisms  are  used 
for  this  function  and  include  a joy  stick,  light  pen, 
or  a track  ball.  Each  of  these  supplemental  cursor 
control  devices  has  advantages  and  disadvantages.  The 
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advantages  lie  primarily  in  the  speed  with  which  the 
cursor  can  he  moved.  The  disadvantages  lie  in  the 
additional  mechanical  and  electronic  equipment 
utilized  in  the  device  itself.  In  the  case  of  the 
joy  stick  and  the  track  ball,  both  mechanical  and 
electronic  linkages  are  Required.  In  the  case  of  the 
light  pen,  electronic  and/or  photosensitive  techniques 
are  used  to  position  the  cursor.  The  ease  with  which 
the  operator  can  use  these  devices  over  a long  period 
of  time  is  important  in  their  selection.  It  should  be 
pointed  out  that  each  of  these  three  types  of  devices 
is  supplemental  to  the  basic  cursor  control  cluster 
of  the  keyboard.  The  use  of  the  various  tabbing  and 
protective  features  in  modern  CRT  display  subsystems 
allows  enhancement  in  the  use  of  the  cursor  control 
cluster.  By  tabbing  to  specific  data  entry  or  select 
points,  the  time  involved  in  using  the  cursor  control 
cluster  may  be  less  than  that  involved  in  using  the 
other  devices,  without  the  need  for  adding  the  dis- 
advantages of  these  devices  to  the  system. 

b . Data  Entry 

There  are  two  typical  classes  of  data  entry.  One  is 
the  classical  function  of  entering  data  into  a format. 
A typical  data  entry  procedure  used  is  to  move  the 
cursor  to  the  desired  value,  enter  the  new  data,  and 
press  an  "ENTER"  function  key.  Many  Vendors  use  the 
protect  mode  of  the  CRT  to  prohibit  the  cursor  from 
residing  on  any  position  other  than  an  enterable 
field,  with  the  format  in  the  protect  mode,  the  cursor 
will  automatically  jump  to  the  first  character  posit- 
ion of  the  next  enterable  field.  This  greatly  facili- 
tates data  entry. 

Verification  of  the  entered  data  then  becomes  neces- 
sary. Partial  verification  is  inherent  in  that  the 
modified  values  appear  on  the  screen  prior  to  pushing 
the  "ENTER"  key.  When  the  "ENTER"  key  is  pushed,  the 
value  is  redisplayed  in  a different  color  to  confirm 
the  acceptance  of  the  value  by  the  system.  There  are 
several  classes  of  verification  used  in  systems.  For 
instance,  alphas  within  numeric  fields  are  checked, 
some  form  of  limit  checking  for  reasonability  of  the 
value  is  typical,  and,  in  many  cases,  the  user  pro- 
grams, such  as  the  AGC  functions,  perform  their  own 
individual  program  validity  checking.  In  the  first 
two  cases,  incorrectly  entered  data  values  can  be 
changed  to  a flashing  red,  while  in  the  third  case, 
the  indication  of  the  incorrect  data  can  be  defined  by 


11-57 


the  verification  program. 

Several  values  may  be  entered  simultaneously  on  a 
single  display.  As  the  "ENTER"  function  key  is  de- 
pressed, all  of  the  changed  values  are  checked  for 
validity.  If  any  one  of  the  values  is  determined  to 
be  invalid,  none  of  the  entries  will  be  accepted.  The 
invalid  data  fields  or  field  can  be  shown  in  flashing 
red  and  the  operator  may  correct  these  and  again  push 
the  "ENTER"  key. 

The  second  type  of  data  entry  is  manual  replacement 
of  data  that  is  telemetered.  It  is  not  necessary  to 
use  the  manual  replacement  approach  on  dynamic  data 
since  the  update  processor  is  constantly  updating  it 
from  the  data  base.  In  the  case  of  manually  replaced 
data,  the  method  is  a little  different.  The  man- 
ual replacement  function  prevents  the  updating  of  the 
value  in  the  data  base  until  the  manual  replacement 
status  is  changed.  The  data  is  placed  into  the  data 
base  and  it  remains  there  until  the  telemetered  data 
update  function  is  reenabled.  To  perform  this  opera- 
tion, the  dispatcher  positions  the  cursor  on  the 
point  and  presses  "MANUAL  REPLACE"  function  key.  The 
new  value  or  status  may  be  entered  and  the  "EXECUTE" 
key  depressed.  The  fact  that  the  value  has  been 
manually  replaced  is  noted  by  either  a character  next 
to  the  data  point,  or  a unique  color  in  which  the  data 
is  shown. 

c . Alarming 

The  alarm  functions  of  the  man/machine  interface  may 
be  implemented  using  alarm  printers  and  CRT  display 
equipment.  Any  alarm  that  occurs  in  the  system  is 
printed  on  the  alarm  printer  and  notification  is 
given  with  the  alarm  light  or  some  other  visual 
effect  on  the  consoles.  The  "ALARM  SUMMARY"  button 
is  used  to  present  the  summary  display  of  all  alarms. 
These  alarms  may  be  categorized  according  to  geograph- 
ic area  or  jurisdictional  responsibility.  As  an  alarm 
comes  into  the  system,  the  device  or  data  value  on 
the  appropriate  one-line  will  be  shown  in  a distinct 
color,  normally  flashing  red.  An  alarm  message  will 
be  output  to  the  printer  and  usually  an  audible 
alarm  will  be  sounded  within  the  system.  Upon  display- 
ing the  alarm  summary,  the  dispatcher  would  see  an 
alarm  message  identical  to  that  printed  out  on  his 
logger.  It  would  be  in  a distinctive  color,  typically 
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red,  with  some  portion  of  the  message  flashing  to 
draw  the  operator’s  attention  to  it.  The  dispatcher 
then  would  have  the  ability  to  acknowledge  the  alarms 
that  were  still  in  the  flashing  state  upon  the  CRT 
screen,  through  the  use  of  an  ’'ALARM  ACKNOWLEDGE" 
button  on  the  keyboard. 

In  addition  to  the  alarm  summary,  other  typical 
displays  such  as  the  inhibit  summary,  the  abnormal 
summary,  and  tag  summary  can  be  displayed  upon  re- 
quest . 

d.  Display  Access 

There  are  several  methods  for  accessing  displays: 
l)  directly  through  function  keys,  2)  an  index  or  over- 
view selection,  3)  paging  buttons,  U)  direct  "poke 
point"  linkage,  and  5)  numeric  or  alpha  entry. 

Typically,  there  is  a system  index  from  which  a 
number  of  display  pages  can  be  accessed  directly.  The 
number  of  displays  accessed  form  the  system  index  is 
limited  only  by  the  number  of  pages  required  to 
display  the  entire  menu  list.  Secondary  menus  can  be 
utilized  for  categories  of  information  that  require 
more  indices  to  be  specified  to  allow  direct  access 
to  large  numbers  of  displays  or  formats.  This  begins 
to  form  the  pyramid  of  display  files.  Paging  forward, 
backward,  up,  down,  right,  and  left  can  be  used  to 
move  either  laterallly  in  a level, or  vertically  in  the 
pyramid.  Paging  sequences  should  be  determined  at  the 
time  the  displays  are  generating  and  should  be  inde- 
pendent of  any  other  direct  display  access  linkage. 

Direct  display  to  display  linkages  should  also  be 
provided  within  the  system.  These  are  usually  function 
provided  through  the  use  of  On-line  Display  Generator 
or  a picture  compiler.  This  type  of  linkage  can  be 
defined  by  the  person  generating  the  display  at  will 
and  is  usually  not  limited,  except  by  the  number  of 
"poke  points"  possible  on  the  display.  As  an  example, 
these  display  linking  "poke  points"  can  be  created 
at  such  places  as  the  first  letter  of  a station  name 
to  allow  linkage  from  an  overview  to  a station  On- 
line. Numeric  key  entry  works  especially  well  if  the 
dispatcher  is  accustomed  to  referring  to  the  sub- 
stations by  number.  If  not,  it  is  still  advantageous 
to  have  as  a tool  because  the  dispatcher  will  begin 
to  remember  some  of  the  display  numbers  very  quickly. 
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The  numeric  selection  method  then  becomes  a short-cut 
for  him.  The  entry  of  alpha  characters  for  identify- 
ing displays  is  more  complex  for  the  system  of  soft- 
ware and  should  usually  be  avoided. 

Typical  of  the  station  oriented  displays  are  one-line 
diagrams  which  are  limited  graphics  representation  of 
the  substation  single-line  diagram. 

Another  type  of  display  is  the  administrative  format. 
This  display  is  an  alphanumeric  tabular  format.  The 
information  on  this  display  is  a summation  of  the 
data  base  and  usually  contains  the  current  value  of 
data,  the  high  and  low  limits  for  data  monitoring, 
conversion  factors,  as  well  as  the  position  of  all 
status  devices  corresponding  to  the  normal  status. 

In  addition,  several  other  conditions  are  usually 
shown  which  indicate  whether  the  value  has  been 
manually  replaced,  inhibited,  tagged,  etc.  The 
administrative  format  is  used  to  change  limit 
formation  and  the  other  data  associated  with  the 
points.  This  is  accomplished  using  the  cursor  posi- 
tioning capability  of  the  system  and  the  "ENTER" 
function  key.  Device  control  is  not  normally  allowed 
from  these  formats..  Another  type  of  station  display 
is  typically  a one-line  presentation  of  the  results 
from  a State  Estimator  or  other  application  program. 
Here  the  operator  can  enter  several  lines  of  infor- 
mation which  is  saved  and  displayed  whenever  the  for- 
mat is  recalled.  Entry  into  the  comments  page  is 
accomplished  by  typing  the  message  in  the  area  pro- 
vided and  depressing  the  "ENTER"  key.  The  previous 
messages  may  be  modified  by  making  the  changes  and 
depressing  "ENTER". 

Other  types  of  displays  are  the  point  summary  dis- 
plays, which  include  the  alarm  display  summary,  the 
abnormal  summary,  the  inhibit  summary,  and  the  tag 
summary . 

Additional  displays  such  as  system  overviews,  indices, 
and  transmission  line  diagrams,  can  also  be  generated, 
and  follow  the  same  basic  criteria  for  control  and 
data  entry. 

e . Supervisory  Control 

Most  systems  allow  for  the  control  of  devices  from  the 
keyboard  via  the  one-line  diagrams.  Normally,  the  pro- 
cedure is  as  follows.  The  appropriate  substation 
On-line  is  selected.  The  cursor  is  positioned  on  the 
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device  to  be  controlled  and  then  the  appropriate 
function  key  is  depressed.  ' The  appropriate  function 
keys  may  be,  "TRIP",  "CLOSE",  "RAISE",  "LOWER",  "TAG- 
SET",  or  "INHIBIT1  SET" , etc.  A verification  message 
should  then  appear  on  the  CRT  indicating  that  the 
point  has  been  selected  and  the  operation  to  be  per- 
formed. The  dispatcher  then  presses  the  "EXECUTE" 
key.  Upon  receipt  of  the  corresponding  change  from 
the  RTU,  the  device  color  and  character  change  on  the 
CRT  and  message  "OPERATION  COMPLETE"  should  be  shown 
on  the  verify  line.  A time  period  check  is  usually 
initiated  upon  selection  of  the  action  and  verification. 
If  no  action  is  taken  before  this  time  period  expires, 
the  point  will  be  reset  and  the  display  returned  to 
the  initial  status.  Similar  action  is  taken  if  the 
dispatcher  pushes  the  "CANCEL"  key  instead  of  the 
"EXECUTE"  key.  If  no  confirmation  of  control  action 
is  received  for  a period  of  time  after  pushing 
EXECUTE,  an  appropriate  diagnostic  message  should  be 
output  on  the  verify  line. 

The  tag  function  and  the  inhibit  function  can  be  per- 
formed in  a similar  fashion. 

Control  of  tap  changers  is  a typical  application  re- 
quiring the  use  of  RAISE  and  LOWER  keys.  The  procedure 
is  as  described  above  except  upon  pushing  the  EXECUTE 
key,  confirmation  of  the  action  is  evidenced  by  a 
change  in  the  data  value  representing  the  tap  position. 
The  point  does  not  automatically  clear.  It  remains 
active  awaiting  another  tap  change  command  as  indica- 
ted by  another  operation  of  the  EXECUTE  key.  The 
point  is  cleared  automatically  upon  exceeding  the 
time  delay  or  upon  execution  of  the  CANCEL  key. 

f . Display  Generation  and  Maintenance 

Because  of  the  number  of  displays  involved  in  the 
typical  systems  today,  a display  generation  capability 
that  allows  the  user  to  easily  build  or  modify 
existing  displays  is  mandatory.  Most  vendors  have 
found  it  necessary  for  their  own  use  when  building 
display  files  for  systems  with  as  many  as  10,000 
displays.  The  display  generator  is  a significant  and 
integral  part  of  the  man/machine  system.  The  display 
generator  should  provide  the  ability  to  link  to  data 
values  and  stored  in  the  data  base  as  well  as  the 
ability  to  link  to  complete  predefined  data  files. 

It  must  provide  the  ability  to  link  display  files 
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for  interdisplay  linkages,  create  linkages  for 
scheduling  programs,  create  linkages  for  passing 
a parameter  to  a program, and  define  ASCII  character 
strings  for  display.  The  display  generator  should 
allow  the  operator  to  specify  function  key  linkages 
at  the  time  of  the  display  generation.  The  key 
linkages  are  normally  used  to  define  which  display 
to  present  when  a key  is  depressed.  Although 
techniques  vary,  the  display  generator  is  usually 
used  first  to  build  a static  format,  and  then  identify 
specific  points  on  that  format,  to  link  it  to  the 
data  base . 

The  Display  Generator  provides  the  linkages  between 
an  existing  data  base  structure  within  the  system 
and  the  display.  The  data  base  structure  is  cheated 
through  the  use  of  the  Data  Base  Generation  software 
module,  then  it  is  maintained  and  updated  or  edited 
via  the  use  of  Date  Base  Maintenance  software.  Both 
the  display  generator  and  the  data  base  generation 
and  maintenance  software  should  be  considered  key  and 
integral  parts  of  the  man/machine  system. 

E . Data  Acquisition  and  Communication  Subsystem 
1.  Introduction 


The  Data  Acquisition  and  Communication  Subsystem  (DACS) 
has  as  its  prime  function  the  transfer  of  current  status  of 
the  electric  system  from  the  field  to  a digitized  data 
base  in  a control  center  computer.  Through  use  of  that 
data  base  by  Man/Machine  and  Applications  Software,  the 
control  center  operators  are  able  to  monitor  and  control 
the  electric  system  according  to  company  established 
operating  procedures.  The  control  center  may  be  designed 
for  energy  control,  SCADA  functions,  or  a combination  of 
the  two.  SCADA  control  centers  provide  the  typical 
functions  of  monitoring,  logging,  and  supervisory  control. 
The  Energy  Control  Center  typically  provides  for  the 
functions  of  generation  control,  security  analysis, 
study  and  logging  applications,  and  may  also  provide  the 
SCADA  functions. 

The  DACS  is  the  interface,  the  data  and  control  path  to 
the  generating  plant  and  substation  equipment,  to  region- 
al control  centers,  to  neighboring  utility  control  centers, 
and  to  a power  pool  control  center.  In  short,  it  is  the 
interface  to  the  external  world.  From  a hardware  stand- 
point, the  interface  is  composed  of  a communications 
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interface  between  the  computer  subsystem  and  the  commun- 
ications circuits.  The  remote  end  of  the  communications 
circuit  may  be  connected  to  programmable  or  hard-wired 
logic  terminal  units  or  to  other  computers.  The  orderly 
transmission  of  data  between  the  energy  control  center 
and  the  terminals  requires  that  communications  line 
discipline  or  protocol  be  maintained,  usually  by  mutual 
operation  of  the  hardware  and  software . 

The  Data  Acquisition  Software  activates  and  controls  the 
operation  of  the  DACS  hardware.  It  will  request  data  from 
the  various  terminals  as  required  to  support  the  opera- 
tional needs  of  the  other  software  in  the  energy  control 
center.  It  will  process  all  received  data  and  create  a 
data  base  which  presents  a digitized  image  of  the  electric 
power  system,  and  which  is  accessible  by  the  other  soft- 
ware. The  Data  Acquisition  Software  will  also  process 
requests  from  all  other  software  for  transmission  of 
supervisory  and  generation  control  commands  to  remote 
terminals  and  for  transmission  of  data/messages  to  other 
computer  centers. 

In  some  systems,  data  concentrators  or  unmanned  sub- 
masters may  be  utilized  to  reduce  communications  costs 
by  routing  a number  of  remote  terminals  through  one 
larger  pseudo  terminal.  Alternately,  the  same  benefit  can 
be  attained  by  party-lining  the  remotes  on  one  communi- 
cations circuit.  Regional  Control  Centers  may  provide  this 
function  in  addition  to  their  normal  role  as  the  Super- 
visory Control  (SCADA)  Center  for  the  region.  The  inter- 
face to  the  company's  business  computers  can  be  used  for 
billing  or  service  functions. 

The  purpose  of  this  section  is  to  introduce  the  reader  to 
the  fundamental  requirements  for  the  DACS  and  the  design 
approaches  that  might  be  used.  The  material  presented 
includes  an  overview  of  the  design  of  a DACS,  descriptions 
of  the  hardware  elements  and  of  the  software  functions. 
System  performance  and  several  design  studies/trade  offs 
are  discussed.  The  discussion  presented  herein  is  intend- 
ed to  expose  the  design  options  rather  than  a single 
design  approach.  It  is  oriented  to  the  questions  - What 
to  consider  in  defining  requirements?  What  hardware  tech- 
niques are  available?  What  are  the  software  functions? 

The  information  presented  is  applicable  to  the  utility 
that  intends  to  provide  the  systems  engineering/integra- 
tion function  as  well  as  for  those  utilities  (the  majority) 
that  will  procure  the  system  from  one  of  a number  of 
qualified  suppliers. 
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2.  Subsystem  Design  Overview 


There  are  many  options  at  the  system  level  that  have  im- 
pact on  the  requirements  for  the  DACS.  Is  the  energy 
control  center  to  be  interfaced  directly  to  the  Remote 
Terminal  Units,  or  will  the  interface  be  to  Regional 
SCADA  Control  Centers?  Does  the  Energy  Control  Center 
interface  to  other  Utility  Energy  Control  Centers  or  a 
Power  Pool  Control  Center?  Are  the  utility's  off-line 
computers  to  be  used?  It  should  be  obvious  that  before 
meaningful  design  of  the  Data  Acquisition  Subsystem  can 
begin,  the  system  level  design  concepts  must  be  formulated. 

It  is  important  to  understand  that  the  requirements  of  the 
Applications  Software  may  also  impact  the  design  of  the 
DACS.  The  electric  system  is  an  analog  network  repre- 
sented by  parameters  that  are  dynamic  and  continuous. 

The  representation  of  the  electric  system  in  the  control 
center  cannot  be  100%  faithful  since  the  control  center 
acquired  data  from  the  electric  system  on  a polling  or 
sample  basis  over  geographically  distributed  communica- 
tions channels.  Thus,  the  data  is  discontinuous;  there  is 
time  skew  between  data;  and  the  current  state  of  the 
system  is  now  instantaneously  available  at  the  control 
center.  These  effects  are  a result  of  the  data  acquisi- 
tion process.  Special  techniques  have  been  used  to  mini- 
mize the.  age  of  data  and  the  time  skew  between  data  to 
satisfy  applications  software  requirements. 

While  there  are  many  possible  designs  and  configurations 
for  a Data  Acquisition  Subsystem,  they  all  have  certain 
basic  equipment  in  common.  Figure  II-l  presents  a 
simplified  system  which  includes  most  elements  of  a Data 
Acquisition  Subsystem.  The  portion  of  the  Data  Acquisi- 
tion Subsystem  which  resides  at  the  Energy  Control  Center 
includes  the  following  major  elements: 

° Communications  Interface  Unit  (CIU)  - provides  a 
path  for  data  and  control  signals  between  the 
computer  subsystem  and  the  communications  channels. 
The  control  signal  path  typically  utilizes  the 
direct  I/O  capability  of  the  computer,  while  data 
is  transferred  in  a parallel,  direct  memory  access 
mode.  Small  systems  with  low  data  rates  may  use  a 
less  expensive  serial  data  interface  into  a multi- 
plexer channel  in  the  computer  subsystem. 
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Figure  II-l  Typical  Configuration  of  a Data  Acquisition  ub system 


o 


Channel  Adapter  (CA)  - provides  for  buffering  of 
data,  (both  inbound  and  outbound),  message  for- 
matting/un-formatting, addressing  checks,  trans- 
mission protocol,  and  error  checks 

° Modem  (Modulator  Demodulator)  - provides  the  digital 
to  analog  transformation  necessary  for  the  transfer 
of  data  over  the  communications  circuit 

° Programmable  Remote  Terminal  Unit  (PTU)  - provides 
the  electrical  interface  to  the  field  device 
sensors/controllers.  Responds  to  requests  for  data 
from  control  center.  Processing  and  control  logic 
is  provided  by  an  internal  microprocessor.  The  PTU 
may  be  fielded  and/or  factory  programmable 

° Local  Data  Unit  (LDU)  - similar  in  function  to  PTU, 
but  is  located  at  the  control  center.  May  have 
parallel  data  path  to  the  computer  subsystem 

° Remote  Terminal  Unit  (RTU)  - a non-programmable 
remote  terminal  unit 

The  design  of  a DACS  for  a specific  application  must  be 
based  on  satisfaction  of  a wide  range  of  requirements 
unique  to  the  application.  These  requirements  originate 
from  many  sources: 

0 Company  operating  policy 

° Physical  and  geographical  characteristics  of  system 

° Other  control  center  functions,  in  particular  appli- 
cations software 

0 Dispatcher  needs 

The  list  could  be  extended  to  more  completely  reflect  the 
uniqueness  of  each  control  center.  Subsequent  sections 
will  explore  some  of  these  requirements  and  how  they 
might  be  satisfied  in  a Data  Acquisition  and  Communica- 
tions Subsystem. 
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3.  Data  Acquisition  Requirements 


The  operation  of  an  energy  control  center  is  fundamental- 
ly dependent  on  the  acquisition  of  data  from  the  system 
under  control.  It  is  only  through  manual  or  automatic 
evaluation  of  the  acquired  or  calculated  data  that 
intelligent  dedisions  may  he  made  relative  to  the  control 
of  the  system.  This  concept  is  not  new  to  the  control 
system  designer,  hut  what  is  frequently  given  inadequate 
treatment  is  the  specific,  written  definition  of  the 
requirements  for  acquiring  data,  for  usage  of  the  data, 
and  for  control  capabilities . This  definition  is  critical 
to  system  design. 

Of  primary  concern  is  the  definition  of  the  characteristics 
for  each  data  point  to  be  acquired.  Data  characteristics 
can  he  defined  in  two  broad  categories:  data  point  type 
and  data  point  attributes.  This  information  not  only  will 
impact  the  design/size/cost  of  the  equipment  (hardware 
and  software)  in  the  Data  Acquisition  Subsystem,  but  will 
also  have  similar  importance  to  the  other  subsystems  of 
the  Energy  Control  Center.  In  particular,  the  Computer 
Subsystem  and  the  Applications  Software  are  impacted  by 
such  data. 

The  definition  of  data  requirements  must  address  the 
system  in  several  phases.  First,  the  requirements  must  be 
projected  at  the  time  the  Energy  Control  Center  is  to 
become  operational.  This  is  usually  one  to  three  years 
in  the  future.  Since  the  system  expansion  plans  (forecasts) 
are  reasonably  valid  for  that  period,  the  near-term  data 
requirements  can  be  accurately  predicted.  However,  the 
magnitude  of  specific  data  required  for  the  initial 
system  data  base  makes  even  this  a sizable  undertaking 
for  most  utilities. 

The  second  phase  for  which  data  requirements  must  be  de- 
fined is  some  arbitrary  point  in  the  future.  Typically, 
this  will  correspond  to  the  expected  useful  life  of  the 
control  center  equipment,  particularly  the  computer 
subsystem.  A period  as  short  as  seven  years  has  been  used. 
This  corresponds  to  the  historical  lifetime  of  older 
generation  equipment.  Current  state-of-the-art  hardware 
design  provides  a longer  useful  lifetime.  A longer  period 
of  12-15  years  is  possible  due  to  the  increased  durability 
and  maintainability  of  the  modern  generation  computers. 
Utility  companies  should  also  consider  the  rapidly 
changing  technologies  and  their  probable  effect  on  the 
life  of  the  control  center  equipment.  The  expandability 
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of  the  equipment  to  accomodate  these  new  technologies 
will  he  a major  factor  in  determining  when  the  equipment 
will  become  obsolete. 

The  primary  purpose  of  defining  the  second  phase  data 
requirements  is  to  define  the  expansion  required  of  the 
control  system.  Again,  this  has  prime  impact  on  the 
computer  subsystem.  Overstatement  of  requirements,  while 
clearly  preferable  to  understatement,  may  unnecessarily 
increase  the  cost  of  the  system  by  requiring  expansion 
capabilities  that  will  never  be  used.  The  utilities  current 
growth  forecasts  should  be  used  to  make  this  project  a 
useful  one.  Specifying  unneeded  expansion  capability 
may  also  reduce  the  number  of  Vendors  capable  (or  desirous) 
of  supplying  such  a system,  thus  offering  the  utility 
fewer  proposed  designs  from  which  to  select. 

a.  Data  Point  Types 

The  definition  of  the  requirements  for  acquired  data 
must  be  stated  in  the  form  of  point  counts  for  each 
RTU  in  the  system.  The  counts  must  be  given  for  each 
point  type.  The  different  major  categories  of  point 
data  types  are  described  below: 

° Discrete  Input  - A point  having  one  or  more 
discrete  states.  May  be  used  for  alarm,  indica- 
tion, sequence  of  events,  or  device  status.  Mem- 
ory status  points  may  be  required  to  retain 
knowledge  of  multiple  device  operations  (such 
as  breaker  trip-close- trip)  between  master 
station  scans.  Extremely  high  security 
applications  might  use  latching  status  which 
remains  set  until  a reset  is  received  from  the 
control  center 

° Analog  Input  - A point  that  is  represented  by  a 
variable  analog  signal.  May  be  used  for  voltage, 
current,  KW,  temperature,  and  other  analog 
measurement . 

° Accumulator  Input  - A point  that  is  accumula- 
ting or  counter  type  measuring  device.  Kilowatt- 
hour  readings  are  typical  accumulator  inputs 

° Control  Output  - Interpos  ing  relays  that  are 
actuated  from  the  control  center  to  operate 
field  devices  such  as  circuit  breakers 
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There  is  other  information  relative  to  each  data 
point  that  the  utility  must  provide  during  the  devel- 
opment phase  as  defined  below.  Requirements  in  the 
Man/Machine  Subsystem  for  display  of  data  and  alarm 
conditions  are  important  basic  needs  for  this  data. 
Much  of  this  data  is  dependent  upon  the  selected 
Vendor's  system  design, and  will  reflect  the  operation- 
al philosophy  desired  for  the  Energy  Control  Center: 

° Name  - The  English  text  name  for  reference  to 
the  data  point  on  CRT  displays  or  printed  logs 

° Color  Coding  - The  manner  in  which  data  point 
is  to  be  presented  (color,  flash  inverse  color, 
etc.)  for  various  system  conditions  represented 
by  the  data 

O 

Alarm  Procedures  - Messages  to  be  displayed  and 
or  logged  when  data  point  goes  into  an  alarm 
state.  Multiple  alarm  list  displays  may  be 
used  to  segregate  alarms  by  dispatcher 
function,  e.g.  transmission,  distribution,  etc. 
Data  points  may  be  logged  on  one  or  more  lists. 
Similarly,  alarm  messages  for  the  data  points 
may  be  logged  on  one  or  more  printing  devices. 
Audible /visual  annunciators  may  be  activated 
to  alert  the  operator.  Different  procedures 
may  be  used  when  points  return  to  their  nor- 
mal state 

0 Data  Usage/System  Correlation  - The  usage  of  a 
particular  data  point  within  the  computer  sub- 
system is  not  usually  of  direct  concern  to  the 
Data  Acquisition  System.  This  information  must 
be  developed  to  define  to  the  supplier  the 
correlation  of  the  data  points  to  the  electric 
system  and  their  usage  in  the  various  applica- 
tions software  functions.  In  some  systems,  a 
data  base  management  technique  may  be  used 
where  structured  identification  numbers  are 
assigned  to  each  data  point.  In  such  cases 
this  assignment  is  of  importance  to  the  design 
of  the  data  acquisition  subsystem  software 

Not  all  data  point  information  is  pertinent  to  the 
specification  phase.  Development  of  some  of  the  in- 
formation can  be  deferred  to  the  implementation 
phase.  However,  the  specification  of  requirements 
and  the  development  of  data  to  support  system  im- 
plementation is  a substantial  undertaking  even  for 
the  smaller  utility. 
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Analog  Output  - A set-point  or  desired  value  to 
be  used  by  a local  device  controller.  Some 
generation  control  approaches  send  desired  gen- 
eration to  the  generator  control  unit  as  an 
analog  setpoint. 

Appendix  C provides  additional  information  related 
to  the  electrical,  mechanical,  environmental,  re- 
liability, and  security  characteristics  of  the  hard- 
ware 

b.  Data  Point  Attributes 


The  definition  of  data  point  attributes  is  in  many 
cases  a subjective  process.  The  following  describes 
the  major  data  characteristics  which  must  be 
defined/considered: 

0 Range  of  Data  - The  maximum /minimum  values 

(counts)  from  the  sensor,  the  scale/bias  factors 
required  to  convert  the  values  to  engineering 
units,  and  the  dead  band  within  which  no  change 
will  be  recognized. 

° Frequency  of  Acquisition  - The  maximum  age 

allowed  for  data  points  in  the  data  base  of  the 
control  center  computers.  Report  by  exception 
techniques  can  sometimes  satisfy  the  requirement 
for  current  data  without  periodic  scans.  Typical- 
ly, data  used  in  generation  control  is  acquired 
at  two  second  intervals , as  is  the  status  of 
breakers  and  other  devices  important  to  system 
operation /security.  Other  data  is  acquired  at 
intervals  of  10-30  seconds. 

° Time  Skew  of  Data  - The  maximum  acceptable  period 
of  time  between  the  sampling  of  various  data 
points  of  a set.  This  is  important  in  several 
cases.  For  instance,  where  there  are  several 
remote  terminal  units  party-lined  on  one 
communications  circuit  and  data  is  to  be  ac- 
quired from  each  unit  for  applications  such  as 
generation  control. Even  when  no  party-lining 
exists,  applications  such  as  state-estimation 
may  have  time  skew  requirements  that  cannot  be 
satisfied  by  the  available  hardware  without 
special  scan  techniques. 
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L.  Typical  Hardware  Elements 


This  section  includes  a description  of  the  two  major 
hardware  elements  or  end  items  in  the  DACS:  the 

Communications  Interface  Unit  (CIU)  and  the  Programmable 
Terminal  Unit  (PTU).  Brief  discussions  of  the  communica- 
tions media  and  of  the  communications  message  standards 
are  also  included.  Both  the  CIU  and  PTU  can  be  micro- 
processor based  units.  The  micro  processor  is  the  key  to 
many  important  capabilities: 

° Adaptability  to  different  message  standards 

° Multi-use  circuit  cards 

° Local  processing  and  control 

0 Low  cost  maintenance 

0 Programmable  remote  units 


It  is  emphasized  that  the  processing  capability  (computer 
speed,  memory  expansion,  word  size,  and  instruction  set) 
of  the  micro  processor  used  in  this  equipment  is  as 
important  to  the  DACS  as  is  the  processing  capability  of 
the  Computer  Subsystem  to  the  Energy  Control  Center.  This 
is  particularly  true  in  the  PTU  where  there  is  the  cap- 
ability for  expansion  of  functions.  This  expansion  cap- 
ability is  predicated  on  the  availability  of  unused 
storage  and  processing  capability. 

a.  Communications  Interface  Unit 


The  Communications  Interface  Unit  (CIU)  is  the  inter- 
face between  the  computer  subsystem  and  the  communi- 
cations channels  to  the  Programmable  Remote  Terminal 
Units  (PTU’s)  and  other  computers. 

Typically,  the  CIU  must  perform  the  following  func- 
tions : 


° Interface  to  multiple  host  computers 
° Buffer  data  to/from  channel  adapters 
° Transfer  data  between  host  computers 
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Provide  switching  of  redundant  .communications 
lines 

° Detect  errors  in  transmission  by  use  of  parity, 
checksums,  cyclic  error  coding,  or  other 
technique 

The  channel  adapters  used  by  the  CIU  must  support  the 
interface  to  several  types  ot  remote  devices.  This 
includes  other  computer  control  centers  and  remote 
consoles,  as  well  as  RTU/PTU’s. 

b . Programmable  Remote  Terminal  Unit 

The  Programmable  Remote  Terminal  Unit  (PTU)  provides 
the  interface  to  field  device  sensors  and  control 
devices.  Typically  the  PTU  will  perform  the  following 
functions : 

O 

Support  communications  line  protocol  and  message 
formats 

O 

Maintain  a local  data  base  of  current  state  of 
all  field  devices 

O 

Receive  and  analyze  requests  from  the  control 
center 

° Format  return  data 

O 

Execute  special  functions,  e.g.  relay  controls 

0 Support  different  data  types: 

Discrete  Input  -momentary  status 

-change  detect  status 
-latching  status 
-pulse  counters 

Analog  Input  -single  ended  input 
-differential  input 

Control  Output  -momentary  control 
-pulse  duration 

Analog  Output  -set  points 

° Provide  other  optional  capabilities: 
status  report  by  exception 
analog  freeze 
sequencd  of  events 
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The  PTU  must  provide  for  security  of  operations.  This 
requirement  includes  automatic  recovery  from  power 
cycling  and  IEEE  surge  withstand  capability.  Various 
function  checks  or  reference  quantity  tests  may  be 
used  to  provide  warning  of  failed  or  degraded  opera- 
tion. 

Many  state-of-the-art  remotes  are  programmable.  This 
means  that  a mini  computer  or  micro  processor  is 
used  instead  of  hardware  logic.  The  programmable  units 
offer  many  advantages  over  the  non-prograramable  types: 
cost /performance  improvements , reduced  number  of  dif- 
ferent hardware  components  (e.g.  printed  circuit  cards), 
improved  diagnostic  capabilities,  and  others.  Most 
important,  they  provide  capability  for  local  process- 
ing and  control.  The  pendulum  of  the  economic  pay  off 
equation  is  swinging  rapidly  toward  more  local  pro- 
cessing applications.  Caution  must  be  exercised  how- 
ever, to  insure  that  the  unit's  programmability  does 
not  compromise  its  security  of  operation.  This  is 
particularly  true  for  field  programmable  units.  The 
potential  future  application  for  programmable  remotes 
includes : 

° Sequence  of  Events  Recording 
° Closed  Loop  Control 
° Local  Data  Collection  and  Logging 
° Equipment  Maintenance  Recording 
° Load  Management 

0 Calculation  of  Parameters  (instead  of  instru- 
mentation) 

° Local  Operations 

The  capabilites  of  the  micro  processor  are  key  to  the 
ability  of  a PTU  to  incorporate  these  additional 
functions.  In  some  designs  programmability  means 
only  the  capability  to  change  message  formats  through 
firmware, with  no  ability  to  handle  the  new  applications. 
The  PTU  should  be  selected  or  designed  with  the  full 
range  of  potential  applications  in  mind. 
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c.  Communications  Media 


The  range  of  options  available  in  the  communications 
portion  of  the  DACS  is  such  that  only  a summary  of 
the  more  frequently  used  techniques  will  be  presented. 
From  the  standpoint  of  the  DACS  there  are  just  a few 
characteristics  that  are  pertinent.  Generally,  all 
communications  interfaces  should  comply  with  EIA 
Standard  RS232C.  Communications  used  for  these  ap- 
plications are  generally  dedicated,  full  period  lines 
as  opposed  to  dial-up  type  circuits. 

Aside  from  the  quantity  of  the  communications  circuit, 
the  DACS  will  have  requirements  for  bandwidth  adequate 
to  support  the  desired  data  transmission  bit  rates. 
These  bit  rates  are  determined  by  the  required  data 
scan  rates,  volume  of  data,  and  numbers  of  PTU's  per 
circuit  (party-lined).  Typical  utility  applications 
use  1200  BPS  circuits  for  interface  to  RTU's.  Inter- 
faces to  other  computer  centers  range  from  1200  to 
9600  BPS.  Remote  consoles,  with  requirements  for  fre- 
quent display  update  of  fast  response  for  display 
requests,  may  require  from  96OO  BPS  up  to  40.8  kBPS 
communications . 

The  communications  media  are  typically  one  or  more 
of  the  following  types : 

0 Voice-grade  land  line 

o Micro-wave 

o Power  line  carrier 

0 Radio 

REA  Bulletins  66-4  through  66-8  cover  these  media 
in  detail. 

A single  circuit  may  be  composed  of  only  one  type  or 
may  be  a combination  of  two  or  more  types  with  suit- 
able interfaces.  Multiple  circuits  may  be  used  to 
connect  remote  units  to  the  Energy  Control  Center.  In 
such  designs,  appropriate  switching  must  be  provided 
at  both  the  control  center  and  at  the  remote  unit. 

This  switching  may  be  by  operation  of  hardware  and/ 
or  software . 

A new  technology  that  is  developing  rapidly  is  that 
of  fiber  optics.  It  appears  to  offer  excellent 
immunity  to  the  normal  sources  of  electromagnetic 
interference.  It  will  probably  have  its  first 
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application  in  power  plants  or  for  local  substation 
control  where  relatively  short  dedicated  lines  can 
be  used. 

d.  Message  Standards 

Message  standards  for  communications  between  the  energy 
control  center  computers  and  Remote  Terminal  Units 
and  other  computers  are  usually  unique  to  each  Vendors 
equipment.  An  understanding  of  the  significance  of 
these  standards  is  important  to  properly  evaluate 
many  areas  of  system  performance  and  expansion  capa- 
bility. In  some  cases  the  message  standard  is  a re- 
flection of  hardware  limitations.  However,  the  message 
standards  may  sometimes  impose  more  restrictive 
limits  on  the  capabilities  of  the  Data  Acquisition 
Subsystem.  This  may  be  due  to  the  message  standard 
itself  or  to  restrictions  imposed  by  the  Data  Acquis- 
ition Software /Firmware . The  significant  character- 
istics of  any  message  standard  include  security, 
efficienct,  addressing  capability,  and  compatibility 
with  other  standards . 

The  security  of  the  message  standard  is  by  far  the 
most  important.  Several  coding  schemes  have  been  used 
to  provide  transmission  security.  These  include 
checksums,  horizontal  and  longitudinal  parity  bits 
per  character,  Bose-Chaudhuri-Hocquenghen  (BCH)  code, 
and  others.  Transmission  errors  are  to  be  expected, 
with  errors  occurring  at  typical  rates  ranging  from 
1 in  lCr  to  1 in  10^  bits  under  normal  operations. 

Even  though  the  Data  Acquisition  System  may  transfer 
data  at  a low  rate,  the  detection  of  these  errors  is 
an  absolute  requirement.  No  scheme  will  provide  100% 
error  detection  under  all  noise  conditions,  so  it  is 
prudent  to  carefully  evaluate  the  hardware  and  soft- 
ware for  adequate  error  checking. 

Transmission  efficiency  is  of  interest  and  sometimes 
becomes  a critical  factor  even  in  a properly  designed 
system.  In  selecting  the  number  and  speed  of  communi- 
cation links,  transmission  efficiency,  error  rate  and 
message  retry  philosophy  must  be  considered. 
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Addressing  capability  is  important  in  that  it  may 
limit  the  expansion  of  the  subsystem  either  in  the 
number  of  PTU’s  (total  or  per  channel)  or  in  the 
number  of  points  within  a PTU.  This  is  due  to  the 
field  size  (number  of  bits)  allowed  for  terminal 
(station)  and  point  addresses. 

Compatibility  with  other  standards  may  be  important 
when  adding  remote  terminals  to  existing  Data 
Acquisition  Subsystems.  In  the  past,  add-on  RTU’s 
were  almost  always  sole  -source  items  to  the  original 
supplier.  However,  with  the  programmable  nature  of 
present  equipment,  many  Vendors  can  supply  add-on 
equipment  using  any  message  standard. 

As  has  been  stated,  there  is  significant  variation 
in  message  standards  used  by  different  Vendors.  In 
recognition  of  this,  the  subsystem  designer  should 
specify  his  minimum  requirements  as  related  to  the 
message  standards  and  not  unnecessarily  specify  the 
message  formats.  Message  standards  should  be  specified 
only  for  existing  equipment  that  will  be  used  in  the 
new  Data  Acquisition  Subsystem. 

5 • Software  Features 


While  the  hardware  elements  provide  the  needed  electrical 
interface  to  acquire  and  route  remote  data,  it  is  the 
software  (firmware)  that  provides  the  intelligence  of  the 
Data  Acquisition  Subsystem.  The  software  defines  what 
data  is  to  be  acquired,  scan/poll  intervals,  data  base 
structure,  processing  of  received  data,  expansion  dapa- 
bilities,  and  user  interfaces  to  the  data  base.  The 
operation  O'f  the  Data  Acquisition  Subsystem  has  few  ex- 
ternal manifestations  that  are  apparent  to  the  control 
center  operations  personnel  as  to  the  Man/Machine  Sub- 
system and  the  Applications  Software.  However,  the  DACS 
is  fundamental  to  the  propoer  operation  of  the  entire 
energy  control  center.  The  major  functions  of  the  Data 
Acquisition  Subsystem  Software  are  discussed  in  the 
following  subsections.  The  Data  Base  is  discussed  first 
as  the  focal  point  for  the  entire  subsystem.  It  is  the 
digitized  image  of  the  electric  power  system. 

a.  Data  Base 


The  data  base  (and  its  structure)  is  of  significance 
to  the  system  designer,  as  it  determines  a number  of 
key  design  parameters.  It  is  a major  component  of 
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computer  storage  requirements  (core  and  auxiliary) 
and  it  will  impact  execution  times  of  other  software 
as  a result  of  the  overhead  associated  with  data 
base  access.  The  data  base  may  provide  a single 
unified  data  base  for  remote  (scanned)  data, and  for 
applications  (calculated)  data,  or  they  may  be 
totally  separate. 

The  data  base  for  remotely  acquired  data  must  include 
not  only  the  current  status/value  of  each  point,  but 
must  also  include  certain  data/flags  regarding  the 
quality  of  the  data  or  operational  state  of  the 
point.  The  requirements  in  this  area  are  highly 
dependent  on  applications  and  operational  (operator) 
requirements . The  typical  data  items  in  the  data  base 
for  the  various  types  of  acquired  points  are  as 
follows : 

0 Status/Indication  Points  - Current  Status 

Normal  Status 

° Analog  Points  - Current  Value 

Scale/Bias  Factors 
High  Limit(s) 

Low  Limit(s) 

Rate  of  Change  Limit  (s) 

° Accumulators  - Value  for  Current  Interval 
Current  Reading 
Rollover  Constant 
Scale  Factor 
Data  Format 

The  data  base  may  include  pointers  to  other  system 
tables  to  support  operation  of  the  software.  Also 
included  in  the  data  base  for  each  point  will  be  a 
set  of  flags  which  define  the  quality  of  the  data  or 
the  power  system  condition  represented  by  the  data 
point.  These  flags  may  apply  to  one  or  more  of  the 
point  types : 

° Deactivated  Flag  - The  data  base  for  the  point 
is  not  to  be  updated  even  if  valid  scan  data  is 
received 

° Telemetry  Error  Flag  - The  data  base  for  the 
point  was  not  updated  on  the  last  scan  due  to 
some  type  of  telemetry  error 
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0 Manual  Data  Flag  - The  operator  has  over-ridden 
the  scan  and  substituted  and  operator  entered 
value . 

0 Point  Selected  Flag  - The  point  is  currently 
selected  by  the  operator  for  some  function 

0 Alarm  Flag  - The  point  is  in  an  alarm  state 

° Acknowledged  Flag  - The  existing  alarm  condition 
has  been  acknowledged  by  the  operator 

° Change  Authorized  Flag  - A change  in  the  status/ 
value  of  the  point  is  expected  and  should  not 
be  alarmed 

° Tagging  Flag(s)  - The  operator  has  applied  a tag 
or  tags  to  the  point  to  inhibit  control  of  other 
functions 

This  list  of  items  in  the  data  base  is  not  all  in- 
clusive. Particular  applications  may  cause  unique 
requirements  for  the  data  base.  In  all  cases,  it  is 
important  to  clearly  specify  requirements  for  func- 
tions that  depend  on  the  existence  of  certain  infor- 
mation in  the  data  base. 

The  particular  layout  of  the  data  base  has  significance 
to  system  performance  due  to  the  overhead  that  may 
exist  for  access  to  the  data  base.  In  many  system 
designs,  access  to  the  data  base  is  through  a single 
set  of  interface  software  called  the  data  base 
manager.  There  are  many  valid  reasons  for  this 
approach : 

0 Allows  virtual  data  base;  makes  users  independ- 
ent of  allocation  of  the  data  base  to  different 
storage  types 

° Can  provide  higher  degree  of  security  against 
unauthorized  change  to  data  base 

° Simplifies  expansion  capabilities 

0 Allows  collection  of  usage  statistics  for  tuning 
performance  of  the  system 

° Reduces  impact  of  reaching  limits  of  core 
memory  expansion 
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Whether  a virtual  data  base  approach  is  used  or  not, 
satisfaction  of  the  basic  requirement  is  dependent 
on  many  parts  of  the  data  base  being  core-resident. 
Frequency  of  access  and  required  response  time  for 
display  call-up,  data  acquisition  scan  cycles,  as 
well  as  the  application,  functions,  will  determine  the 
allocation  of  storage  to  the  database.  Usually,  the 
entire  data  base  for  remote  (scanned)  data  will  be 
core  resident  to  satisfy  these  requirements. 

b . Data  Acquisition 

The  Data  Acquisition  Software  supports  message  exchange 
sequences  for  all  scan  modes,  generates  the  necessary 
commands  for  information  required,  performs  error 
checking  to  assure  the  validity  of  data  and  the 
proper  completion  of  scan  requests,  and  updates  and 
maintains  the  data  base.  In  addition,  the  Data 
Acquisition  Software  provides  support  for  the  super- 
visory control  functions  by  transmitting  commands, 
timing-out  the  operation,  and  performing  error  checks. 

Data  may  be  received  on  a cyclic  basis  or  by  exception 
The  Data  Acquisition  Software  must  allow  for  multiple 
cyclic  scans,  each  having  assigned  priority  and 
interval  between  scans.  For  each  such  scan,  the 
software  must  format  the  appropriate  data  request, 
transmit  the  request,  and  check  the  return  transmission 
for  errors. 

All  valid  received  data  is  then  subjected  to  process- 
ing according  to  the  data  type.  The  received  data  and 
any  associated  derived  quality  data  is  entered  into 
the  data  base.  Typical  processing  requirements  are 
primarily  oriented  to  detection  of  alarm  conditions, 
which  is  discussed  in  a later  section.  Other  pro- 
cessing of  data  might  include  conversion  of  analog 
data  to  engineering  units,  and  calculation  of  time 
interval  (hourly)  values  for  accumulator  points. 

Performing  the  complete  Data  Acquisition  Function  for 
all  remote  points  on  a fixed  cyclic  basis  can  over- 
load the  computer  system  and/or  the  communications 
channels  and  may  cause  unacceptable  time  skew  in 
the  received  data.  This  possibility  is  important  be- 
cause, in  many  systems,  communications  represent  the 
largest  single  cost  element.  In  order  to  minimize 
communications  channel  bandwidth  requirements,  a 
Report  by  Exception  scheme  is  frequently  utilized. 
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Other  approaches,  such  as  quiescent  remotes,  have 
been  used.  Quiescent  remotes  transmit  device  status 
to  the  control  center  computers  on  a change  or 
interrupt  basis.  Since  these  transmissions  are  not 
controlled  by  a single  master,  the  potential  exists 
for  simultaneous  transmissions  by  multiple  remotes 
on  the  same  communications  circuit.  Special  software 
is  usually  required  for  some  situations,  such  as 
turning  off  all  remotes,  then  turning  them  back  on, 
one  at  a time.  For  that  reason,  and  others,  the  Report 
by  Exception  Approach  seems  to  be  favored  by  most  of 
the  industry. 

c.  Report  by  Exception 

In  the  Report  by  Exception  Approach,  a polling  tech- 
nique, is  used  instead  of,  or  in  combination  with,  the 
scan  approach.  This  technique  typically  includes 
the  following  steps: 

° The  Data  Acquisition  Software  sends  a poll  to 
each  PTU  at  periodic  intervals 

° The  PTU  responds  to  the  poll  with  a report  that 
data  has  (or  has  not)  changed 

0 The  Data  Acquisition  Software  must  then  issue  a 
scan  request  to  acquire  changed  data 

This  approach  is  particularly  advantageous  when  there 
are  large  numbers  of  status  points  which  change 
state  only  infrequently.  Reporting  by  exception  can 
also  be  applied  to  analog  points  by  use  of  a change 
threshold.  For  example,  the  threshold  could  be 
defined  as  a change  in  the  third  (or  higher)  least 
significant  bit  since  last  reported  change  for  this 
point.  This  represents  only  0.1#  of  the  range  for  the 
12  bit  value,  which  is  less  than  the  combined  accura- 
cy of  sensors  and  conversion  equipment. 

There  is  a shortcoming  of  Report  by  Exception,  how- 
ever. While  it  does  greatly  reduce  the  communications 
loading  under  most  conditions,  it  can  present  heavier 
loading  than  the  scan  technique  under  conditions  of 
frequent  and  continuing  change.  This  is  due  to  the 
fact  that  the  Report  by  Exception  approach  requires 
additional  overhead  in  the  message  structure  for 
point  identification.  Also,  if  points  change  rapidly 
and  continually,  they  may  be  scanned  more  frequently 
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than  they  would  have  been  scanned  under  periodic 
scan  approach.  It  is  important  to  understand  the 
conditions  under  which  the  communications  system 
becomes  saturated  and  the  impact  this  might  have 
on  the  operation  of  the  Energy  control  Center. 

This  shortcoming  of  Report  by  Exception  manifests  it- 
self when  it  is  least  desired,  i.e.  during  system 
disturbances.  In  some  systems  it  may  even  be  self- 
defeating  due  to  this  anomaly.  Careful  and  prudent 
design  is  essential.  A hybrid  design  approach  that 
could  alleviate  this  problem, is  one  where  in  the 
high  rate  of  change  and  memory  status  points  are 
periodically  scanned, while  slow  rate  of  change  status 
points  are  reported  by  exception. 

d.  Error  Detection 

It  is  imperative  that  the  Data  Acquisition  Software 
prevent  invalid  data  from  entering  the  data  base. 

All  received  data  must  be  checked  for  errors . The 
following  categories  of  errors  may  be  detectable: 

° Channel  adapter  and  PTU  hardware  detected  errors 

° Communications  interface  hardware  detected 
errors 

Timeout 

Transmission  errors 

Inoperative 

Data  transfer  errors 

° Software  detected  errors 
No  response 
Data  overrun /underrun 
Data  identification  errors 

The  specific  errors  in  each  category,  to  a large  ex- 
tent, are  dependent  on  hardware  design.  It  is 
important  that  all  available  error  indications  be 
utilized  and  that  the  basic  requirement  is  satisfied 
that  no  invalid  data  enter  the  data  base. 

Some  form  of  error  statistics,  e.g.  daily  error 
count  by  error  type , should  be  maintained  to  aid  in 
diagnostic  and  corrective  action.  In  addition,  a 
short  term  error  rate  may  be  the  basis  for  alarming 
marginal  operation  or  failure  of  equipment. 
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e.  Alarm  Detection 


One  of  the  more  important  functions  of  the  Data 
Acquisition  Subsystem  is  that  of  the  alarm  detection. 
Normally,  all  scanned  data  is  subjected  to  some 
type  of  check  to  determine  whether  a point  should  be 
alarmed  to  the  operator.  The  following  types  of 
checks  are  typical: 

° Status  Change  - Status/indication  point  has 
changed  state  since  last  scan.  An  unauthorized 
change  alarm  should  be  issued  unless  the  change 
was  authorized,  in  which  case  a completion  of 
operation  message  should  be  issued.  Change 
detection  may  include  distinction  of  single  and 
multiple  changes  of  state  betwen  scans 

° Limit  Checks  - Analog  values  may  be  tested 
against  one  or  more  sets  of  limits.  Alarms  are 
generated  if  limits  are  exceeded.  Sets  of  limits 
may  be  provided  for  operational,  emergency,  or 
other  conditions 

° A specified  number  of  alarms  must  be  CRT 

displayable  in  one  or  more  alarm  list  displays. 
Procedures  for  overflow  of  the  lists  must  be 
defined 

° Alarms  which  occur  during  a time  window  immedi- 
ately preceding  a failover  may  be  lost.  Systems 
have  been  implemented  with  this  time  window  as 
small  as  100  milliseconds.  In  most  systems, 
that  requirement  can  be  relaxed  somewhat  since 
the  first  scan  after  failover  would  "re-detect" 
the  "lost"  alarms  if  they  still  existed 

f . Supervisory  Control 

The  Supervisory  Control  Software  Functions  are 
typically  thought  of  as  a man/machine  function, 
however,  the  Data  Acquisition  Software  usually  will 
have  the  responsibility  for  actual  communications 
with  the  PTU  where  the  control  is  to  be  actuated. 

This  software  must  support  several  functions  and 
modes  of  operation.  The  primary  responsibilities  are 
the  formatting  of  the  control  messages,  transmission 
of  the  messages,  and  validation  of  the  checkback 
according  to  the  defined  message  protocol. 
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Both  immediate  operate,  and  select-then-operate  modes 
are  used.  The  immediate  operate  mode  is  used  for  rep- 
etitive type  operations  where  communications  time 
must  be  minimized.  Typically,  generation  control  app- 
lications will  use  the  immediate  operate  mode. 

The  select-then-operate  mode  is  used  for  operator 
supervisory  control  functions.  This  mode  requires  a 
select  message  to  the  PTU,  and  a final  checkback 
response . 

The  security  of  the  control  operation  provided  by 
the  combined  functioning  of  the  Data  Acquisition 
Hardware  and  Software  is  of  paramount  importance.  No 
error  or  failure  mode  should  allow  unauthorized 
operation  of  a control  relay. 

g . Failover  Considerations 

The  Data  Acquisition  Software,  together  with  the  other 
software  subsystems,  must  make  provision  for  failover 
to  the  backup  system  in  case  of  critical  failure  to 
the  system  operating  in  the  primary  mode.  Typically, 
this  will  entail: 

° Transfer  of  the  data  base  to  the  alternate 
system  at  intervals,  usually  30  seconds 

0 Transfer  of  Subsystem  expansion  updates  after 
validation 

° Re-initialization  after  failover 

Restore  data  base  to  the  last  snapshot 
Restart  all  scans 

Abort  or  restart  control  sequences  that 
were  in  progress 

Data  base  snapshots  may  also  be  placed  on  the  primary 
system's  disc  to  allow  for  primary  system  restart 
after  critical  failure,  when  the  backup  system  is  not 
available . 

h . Subsystem  Expansion 

The  Data  Acquisition  Subsystem  must  be  capable  of  easy 
expansion  as  the  power  system  itself  expands.  This 
expansion  is  by  growth  in  point  count  in  existing 
remotes,  by  the  addition  of  new  remotes,  and  by  addi- 
tion of  new  functions  (e.g.  sequence  of  events)  in 
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existing  remotes.  It  should  not  be  necessary  to  take 
the  system  off-line  to  perform  this  expansion.  The 
system  should  be  capable  of  fast  restoration  of  a 
prior  system  in  the  event  that  the  expanded  system 
is  defective.  Security  checks  should  be  provided  to 
detect  erroneous  inputs,  and  to  prevent  their  entry 
into  the  data  base. 

Many  different  techniques  have  been  used  for  this 
function  and  several  are  basically  acceptable.  The 
two  basic  approaches  are  source  data  cards  and  CRT 
interactive  input  techniques.  The  preferred  approach 
is  the  latter,  as  it  eliminates  the  problem  of  card 
handling,  provides  for  timely  error  collection,  and, 
in  the  better  designs,  provides  step-by-step  input 
instructions.  With  the  CRT  approach  it  is  imperative 
that  the  system  provide  capability  for  a test  data 
base  and  a saved  data  base.  These  capabilities  allow 
for  suitable  backup  for  restoring  the  system  after 
hardware  failure. 

A capability  of  dual  or  parallel  primary  is  quite 
useful  for  checkout  of  subsystem  expansion.  The  dual 
primary  mode  of  operation  is  one  wherein  the  backup 
CPU  is  assigned  only  the  equipment  to  be  tested, and 
possibly  a console.  The  Backup  CPU  then  acts  as  if  it 
were  in  the  primary  mode,  executing  all  primary 
software  functions,  but  having  access  only  to  the  equip- 
ment under  the  test.  This  allows  for  a fully  integrat- 
ed checkout  of  the  expanded  data  base,  software 
changes  (if  any),  and  the  new  hardware. 

i . System  Performance  Analysis 

Proper  design  and  implementation  of  a Data  Acquisition 

Subsystem  requires  a number  of  analytical  studies  to 

validate  that  the  proposed  approach  does 

satisfy  all  system  performance  goals.  Many  trade-offs 

are  possible.  The  following  briefly  summarizes 

several  of  the  more  important  analyses  that  should  be 

performed: 

° Communications  Timing  Analysis  - Can  communica- 
tions support  all  periodic  scan  cycles  and 
random  events  such  as  report  by  exception, 
sequence  of  events,  supervisory  controls, 
noisy  communications,  etc? 
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Computer  Subsystem  Storage  Requirements  - Size 
of  the  computer  core  storage  and  auxiliary 
memory  required  to  support  the  Date  Acquisition 
Subsystem 

° Computer  Subsystem  CPU  Time  Utilization  - Is 
CPU  utilization  by  Data  Acquisition  Subsystem 
consistent  with  system  design? 

0 Auxiliary  Memory  Utilization  - This  analysis  is 
important  when  the  major  parts  of  the  real-time 
data  base  and  of  the  Data  Acquisition  Software 
reside  in  Auxiliary  Memory.  Is  the  Auxiliary 
Memory  utilization  consistent  with  the  system 
design? 

0 Response  Time  - This  study  defines  the  ability 
to  maintain  scan  rates,  to  detect  alarms  within 
a reasonable  time  after  their  occurrence  in  the 
field,  and  to  provide  data  to  Applications  Soft- 
ware having  an  acceptable  time  skew. 

In  addition,  if  the  remote  terminal  units  are  pro- 
grammable, it  may  be  necessary  to  perform  Computer 
Subsystem  Storage  Requirements,  Computer  Subsystem 
CPU  Time  Utilization,  and  Response  Time  Studies  for 
the  PTU's  also. 

To  begin  such  an  analysis,  it  is  necessary  to  collect 
data  such  as  PTU  point  counts,  scan  cycles,  character- 
istics of  the  Data  Acquisition  Software.  Also,  time- 
lines or  scenarios  must  be  defined  that  are  to  repre- 
sent system  operation.  This  is  a critical  aspect  of 
the  analysis,  as  a non- representative  timeline  will 
cause  the  study  results  to  be  non-relevent . It  is 
important  to  analyze  several  timelines: 

° Normal  loading  (over  a long  interval,  e.g.  30 
minutes ) 

0 Heavy  loading  (over  a short  interval,  e.g.  30 
seconds ) 

° Word.t  case  loading 

The  heavy  loading  period  over  a shorter  interval  should 
place  emphasis  on  demand  type  events.  The  worst  case 
loading  situation  is  always  of  concern  to  assure  that 
system  operation  remains  acceptable. 
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The  analysis  should  reveal  any  instances  of  under/ 
over  design.  Certain  trade-offs  are  available  to 
correct  designs  that  results  in  unacceptable  perform- 
ance. First  of  all,  the  basic  data,  sizing,  and  time- 
lines, should  be  examined  to  re-evaluate  their  repre- 
sentativeness. If  the  problems  persist,  then  changes 
to  the  system  design  must  be  considered.  While  it  is 
not  possible  to  give  explicit  solutions  to  undefined 
system  problems,  the  solutions  to  be  considered  may 
include  one  or  more  of  the  following: 

° Use  faster  communications  media 

0 Scan  the  PTU’s  less  frequently 

° Use  multiple  scan  cycles  to  effectively  reduce 
scan  rate 

° Use  polling /Report  by  Exception  techniques.  This 
is  most  frequently  used  for  status  points  only, 
but  could  also  be  applied  to  analog  points 

° Reduce  extent  of  party-lining  of  PTU's.  This 
allows  more  parallel  communications,  but  may  in- 
cur substantial  communications  costs 

° Distribute  processing  with  intelligent  (pro- 
grammable) PTUs 

° Expand  the  Computer  Subsystem 

° Add  :"Froht  End"  Processor 

Quite  frequently  conflicting  requirements  occur  where 
the  utility  desires  to  party-line  many  remotes  due  to 
the  radial  nature  of  their  system  and  the  cost  of 
communications  circuits.  This  conflict  occurs  because 
of  the  various  data  acquisition  cycles:  the  generation 
control  function  (normally  at  2 second  intervals), 
the  study  programs  (normally  at  10-30  second  intervals, 
but  time  skew  of  data  is  critical) , and  the  normal 
dispatcher  SCADA  functions  of  monitoring,  logging, 
and  supervisory  control.  Such  a conflicting  situation 
existed  on  a system  in  development  at  TRW.  The  result- 
ant solution  involved  use  of  Report- -by  Exception  for 
status  points,  and  an  "analog  freeze"  capability  to 
snapshot  analog  values  at  all  PTUs,  with  one  universal 
command  followed  by  transmission  of  the  analog  data 
back  to  the  control  center,  over  a 20  second  interval. 
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j . Other  Considerations 


Other  aspects  of  the  DACS  must  be  given  consideration 
as  part  of  the  design  process.  These  include  the 
testability,  maintainability,  spare  parts  inventory, 
and  training  requirements,  among  others. 

Diagnostic  capabilities  are  very  important,  particu- 
larly with  programmable  devices.  Diagnostic  testing 
tools  may  be  software  or  hardware,  integral  with  on- 
line DACS,  or  stand-alone.  These  diagnostic  tools, 
together  with  the  error  detection/reporting  capability 
of  the  hardware,  will  significantly  impact  time-to- 
repair,  which  in  part,  determines  the  availability 
of  the  subsystem.  Programmable  units  typically  are 
provided  with  several  types  of  diagnostic  capabilities 

O 

In-pldnt  microprocessor  based  diagnostic  systems 
are  used  for  board  test  and  automated  testing 
of  end  items,  such  as  PTUs  and  CIUs 

o 

A portable  maintenance  panel  is  a field 
diagnostic  device  which  provides  capabilities 
such  as  display  to  all  registers,  address  stop, 
single  step,  single  cycle,  and  others 

° Portable  analyzer  units  can  emulate  a PTU  or  CIU 
and  can  provide  for  display  of  received  data, 
for  operator  definition  of  transmitted  data, 
for  selected  error  checking,  and  for  simulation 
of  error  conditions 

O . / 

Firmware /software  diagnostic  can  Check: 

Basic  harware  interfaces 
Complete  instruction  set 
Memory 

All  I/O  cards  - channel  adapters,  discrete 
input,  analog  input,  accumulator  input,  con- 
trol output,  analog  output,  and  discrete 
output  s 

The  commonality  of  the  hardware  is  also  to  be  given 
consideration.  The  numbers  of  different  printed 
circuit  card  types  used  will  impact  training, 
spares  requirements,  and  system  maintenance /availabil- 
ity. For  example,  typical  equipment  configurations 
will  have  common  basic  structures  for  the  CIU,  PTU, 
and  man/machine  equipment.  Only  the  I/O  cards  vary. 
Even  there,  the  multiplicity  of  card  types  could  be 
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reduced.  For  example,  a single  discrete  input  card 
with  appropriate  firmware  can  support  either  momentary 
status,  change  detect  status,  latching  status,  and 
pulse  count  accumulation. 

Maintenance  philosophy  for  both  hardware  and  software 
should  be  defined  early  in  the  project  cycle.  If  the 
Borrower  desires  to  perform  its  own  maintenance, 
staffing  and  training  of  the  personnel  should  be 
planned.  Consideration  should  be  given  to  their 
participation  in  development  of  the  system  at  the 
Vendor's  facility.  Usually  this  approach  provides  the 
benefits  of  more  complete  in-plant  testing,  easier 
transition  during  field  start  up  of  the  system,  and 
shortened  down  times  due  to  hardware /software  failures. 
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III.  DESIGN  CONSIDERATIONS  AND  CONSTRAINTS 


A.  System  Functions 

The  functions  contingent  to  the  planning  for  the  establish- 
ment of  an  Energy  Control  System  (ECS)  are  covered  in  this 
section.  The  functions  are  based  on  an  evaluation  of  "across- 
the-board"  long  range  requirements  determined  via  discussions 
between  engineering  and  system  operating  personnel,  and  are 
consistent  with  standard  equipment  offerings  of  control 
equipment  manufacturers.  The  functions  given  here  are  judged 
to  be  important  to  system  operations , and  can  be  both  economic- 
ally justified  and  easily  implemented  in  the  control  system. 

For  economic  and  efficiency  reasons,  not  all  of  the  functions 
listed  need  to  be  purchased  for  the  initial  system.  Some 
can  be  added  at  installation  time  or  at  some  time  in  the 
future.  Any  vendor  should  be  required  to  provide  a system 
capable  of  performing  all  of  these  functions,  even  though 
complete  system  hardware  may  not  be  initially  purchased. 
Designation  of  the  vendor  or  the  borrower,  , as  a supplier  of 
a particular  functional  program  should  be  done  in  the  system 
specification  stage.  During  the  specification  stage,  selected 
functions  should  be  described  in  qualitive  and  numerical  de- 
tail to  aid  the  vendor  in  supplying  a system  which  will  satA 
isfactorily  perform  them.  After  vendor  proposals  have  been 
received  and  reviewed,  a final  decision  of  programming 
responsibility  should  be  made. 

A few  of  the  functions  discussed  are  sufficiently  advanced, 
or  may  be  particularly  unique  to  the  selected  operating 
philosophies.  These  functions  are  described  herein  as  option- 
al. Separate  pricing  for  them  should  be  solicited  in  speci- 
fications so  that  their  cost  effectiveness  can  be  judged. 

1 . Automatic  Generation  Control 

An  AGC  program  should  provide  for  the  regulation  of  the 
net  power  output  of  generators  in  response  to  changes  in 
system  frequency,  tie  line  loading, or  the  relation  of 
these  to  each  other,  so  as  to  maintain  the  scheduled 
system  frequency  or  the  established  net  interchange  with 
other  companies  within  predetermined  limits.  The  program 
should  include  provisions  for  the  control  of  the  required 
number  of  dispatch  -units,  operate  at  a programmer  or 
engineer  adjustable  timing  in  the  range  from  one  to  ten 
seconds,  and  provide  for  digital,  non-linear  filtering 
of  the  calculated  Area  Control  Error  (ACE). 
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The  AGC  program  should  distribute  control  signals  to  units 
under  control  to  satisfy  the  system  regulating  obligation 
in  proportion  to  regulating  participation  factors  entered 
by  the  System  Dispatcher.  Economic  distribution  of  gener- 
ation would  also  be  maintained  by  moving  units  in  relation 
to  base  points  and  participation  factors  produced  by  the 
Economic  Dispatch  calculation.  The  AGC  will  operate  in 
either  a permissive  or  command  mode  depending  upon  the 
level  of  ACE  and  control  status  of  units.  An  emergency 
assist  mode  will  be  entered  automatically  if  ACE  exceeds 
a predetermined  MW  level  or  upon  operator  action.  A 
variety  of  unit  control  modes  should  be  available  for 
selection  by  the  System  Dispatcher  to  allow  individual 
units  to  be  on  or  off  control,  to  participate  in  regula- 
tion or  economic  dispatch,  or  to  be  manually  controlled 
and  base  loaded.  Unit  output  should  be  constantly  compared 
to  system  dispatcher  entered  generation  and  rate  limits 
and  unit  output  maintained  within  these  limits. 

2.  Economic  DispAtch  (ED) 

Tools  should  be  provided  to  assist  the  System  Dispatcher 
in  producing  base  points  and  participation  factors  to 
cause  the  AGC  programs  to  economically  distribute  total 
required  generation  among  units  on  line.  As  a minimum,  a 
capability  should  be  available  to  display  unit  increment- 
al cost  data  to  allow  System  Dispatchers  to  select 
economic  operating  points. 

Since  the  complexity  of  any  task  will  increase  substan- 
tially when  future  generating  units  at  remote  sites  are 
installed,  consideration  should  be  given  to  a more 
sophisticated,  automatic  ED  calculation.  This  program 
should  optimize  the  incremental  cost  of  power  delivered 
by  considering  unit  incremental  cost  curves  and  manually 
entered  transmission  penalty  factors.  The  ED  should  be 
performed  periodically  of  upon  the  occurence  of  one  of 
the  following  events:  significant  change  in  in  system 
load,  change  in  the  status  of  any  dispatch  unit,  or 
dispatch  request.  Criteria  controlling  the  running  of  the 
ED  and  its  data  parameters  should  be  under  system  dis- 
patcher control.  The  ED  program  should  reflect  cost 
curves  with  polynomial  coefficients,  or  multiple  straight 
line  segments,  and  should  have  the  capability  for 
dispatching  both  controlled  and  non-controlled  generators. 
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3 . Interchange  Scheduling 


The  interchange  scheduling  program  should  provide  time- 
scheduled  power  flow  information  based  on  a library  of 
pre scheduled  transaction.  The  output  of  the  interchange 
scheduling  program,  would  be  used  by  the  AGC  program. 

The  library  should  contain  three  categories  of  transac- 
tions: (l)  transactions  previously  scheduled  and  timed 
out  (last  2k  hours  only);  (2)  tranaactions  presently  in 
progress;  and  (3)  transactions  scheduled  for  the  future. 
The  program  should  determine  the  desired  instantaneous 
net  interchange  and  ramp  for  those  transactions  in  the 
second  category.  The  program  should  also  provide 
running  totals  for  various  types  of  schedules,  plus 
associated  costs  to  be  used  for  monthly  billings.  In- 
advertent interchange  balances  should  also  be  maintain- 
ed. 

The  program  should  include  the  capability  for  the 
System  Dispatcher  to  add  new  transactions  to  the  library 
to  begin  immediately  or  at  any  time  within  the  next 
2k  hours.  All  system  dispatcher  entries  and  deletions 
from  the  schedule  should  be  logged.  A message  indica- 
ting an  impending  transaction  should  be  presented  to 
the  system  dispatcher  five  minutes  before  the  start  of 
the  transaction.  The  instantaneous  tie  line  flows  at 
the  beginning  and  end  of  each  scheduled  interchange 
transaction  should  be  logged. 

The  System  Dispatcher  should  have  the  capability  of 
entering  transactions  with  several  interconnected 
companies,  with  at  least  eight  different  transaction 
types  (e.g.,  emergency,  replacement,  economy  or  surplus). 
The  program  would  apply  programmer  or  engineer  change- 
able cost  factors  to  these  transactions,  or  where 
appropriate,  except  cost  data  from  the  system  dispatchers. 
Transmission  loss  factors  assessed  by  the  utilities 
should  be  automatically  applied  to  each  transaction 
in  keeping  with  programmer  or  engineer  entered  contrac- 
tual provisions.  The  System  Dispatcher  should  have  the 
capability  to  modify  any  of  these  factors.  The  program 
should  display  both  the  nominal  value  of  each  inter- 
change, and  the  actual  value  corrected  for  transmission 
loss  requirements. 

The  Borrower  may  be  required  to  supply  energy  to  the 
interconnected  utilities  to  offset  their  transmis- 
sion losses  in  moving  power  from  the  generation  facil- 
ity to  its  load.  The  Interchange  Scheduling  Program 
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should  automatically  calculate  these  transmission  loss 
requirements  for  each  group  or  load, and  synthesize 
corresponding  scheduled  interchanges.  This  calculation 
should  be  performed  periodically,  at  a rate  adjustable 
by  the  programmer  or  engineer,  in  the  range  from  one 
minute  to  one  hour.  The  total  load  including  transmission 
loss  requirement  for  each  of  the  interconnected  utilities 
shall  be  available  for  real-time  transmission  to  the  in- 
dividual utility  control  centers. 

b.  Supervisory  Control  and  Data  Acquisition 

System  Dispatchers,  who  are  responsible  for  system 
control  and  security,  require  a comprehensive,  quantitive 
representation  of  the  power  system.  Data  should  be  tele- 
metered digitally  from  generating  plants,  substations, 
and  bulk,  delivery  or  metering  points,  at  the  various  rates 
necessary  for  satisfactory  performance  of  all  system 
functions.  Status  data  should  be  scanned  at  high  rates 
(every  two  seconds).  Generation,  tie  line,  and  metering 
point  flows,  should  also  be  telemetered  every  two 
seconds  to  provide  timely  inputs  to  the  AGC  program.  Less 
critical  data  should  be  scanned  at  longer  intervals . 

(every  ten  or  thirty  seconds,  or  one  hour  for  MWH  and 
MVARH  metering)  to  provide  system  monitoring  of  the 
complete  system  and  updated  information  to  other  functions. 

The  new  system  should  provide  the  system  dispatchers  with 
the  capability  to  select  and  control  remote  devices  such 
as  breakers  and  motor  operated  disconnects.  Control 
actions  would  be  accomplished  via  a CRT  display  exhibi- 
ting the  device  to  be  actuated.  Inadvertent  operation  of 
devices  would  be  prevented  by  requiring  a system  dis- 
patcher to  verify  his  selection  of  a particular  device 
before  control  action  can  take  place.  The  system  would 
automatically  confirm  the  accuracy  of  the  selection  at  the 
remote  site  and  verify  correct  operation  of  the  device  by 
subsequent  scanning  of  its  status.  The  new  system  should 
automatically  log  all  control  actions  executed  by  the 
system  dispatchers  in  a chronological  log.  The  types 
of  supervisory  control  to  by  provided  are  described  below. 

a.  On /Off  Control 


On/Off  devices  include  breakers,  disconnect  switches, 
reclosing  relays,  and  underfrequency  relays.  The  new 
system  should  report  the  status  of  all  two-state 
devices,  including  high-speed  reclosing  breakers, 
recognize  the  different  response  times  of  various 
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devices,  and  provide  the  System  Dispatcher  with  an 
indication  that  a control  action  is  in  progress  or 
has  been  completed.  The  initial  system  should  be 
capable  of  controlling  all  on/off  points  to  be  in- 
corporated during  the  life  of  the  computer  system. 
On/off  control  includes  control  and  indication 
points  describing  the  present  state  and  operation  of 
automatic  equipment  at  remote  locations.  Memory  should 
be  provided  at  RTUs  to  indicate  any  operation  of  the 
equipment  occurring  between  scans. 

Controllable  devices  will  be  provided  with  a Local 
Remote  Blocking  Switch  on  the  substation  switchboards, 
to  prevent  operation  when  maintenance  is  being  per- 
formed. The  status  of  each  of  these  switches  should 
be  telemetered  and  displayed  to  the  System  Dispatcher 
and  the  software  should  prevent  any  attempt  to 
control  blocked  devices. 

b . Control  of  Tap  Changing  Transformers 

The  ECS  should  monitor  and  provide  for  system 
dispatcher  control  of  tap  changing  transformers. 

Each  transformer  is  controlled  by  two  sets  of  contacts 
(l)  Automatic /Manual  (mode  control),  (2)  Raise/Lower 
(action  control).  Automatic  control  refers  to  a local 
automatic  control  loop  at  the  substation.  If  the  trans 
former  in  question  is  in  the  automatic  mode,  a system 
dispatcher  would  first  change  the  control  mode  to 
manual.  Once  the  transformer  is  in  manual  control  mode 
a System  Dispatcher  could  raise  and  lower  the  tap 
position  which  would  be  continuously  displayed  to 
him.  When  control  action  is  initiated,  the  software 
should  monitor  the  tap  position  to  ensure  that  the 
desired  action  has  been  accomplished.  A message 
indicating  either  successful  or  unsuccessful  control 
action  should  be  recorded  for  each  control  action 
attempted.  Any  attempt  to  initiate  a raise/lower 
control  action  to  a transformer  in  the  automatic 
mode  shall  generate  an  error  message.  In  some  cases, 
two  or  more  transformers  should  be  operated  as  a 
■unit.  These  sets  of  transformers  have  a common  Auto/ 
Manual  control  and  indication  point.  If  the  trans- 
formers are  in  Auto,  the  local  control  element  keeps 
the  transformers  within  one  tap  position  of  each 
other.  In  Manual  mode  a System  Dispatcher  should 
have  the  option  of  stepping  the  transformers  sim- 
ultaneously (for  paralled  banks  in  station)  or  indepen- 
dently. The  computer  will  monitor  the  tap  position  of  each 
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transformer  in  a paralleled  group  and  initiate  an 
alarm  whenever  they  are  more  than  one  tap  position 
apart . 

5 . Data  Processing 

The  ECS  should  perform  routine  data  processing  on  all 
telemetered  variables.  Each  value  would  be  converted  to 
engineering  units,  tested  for  reasonablity  and  checked 
against  dispatcher  enterable  upper  and  lower  limits.  The 
computer  system  should  have  the  capability  for  creating 
calculated  variables  which  are  formed  by  using  programmer 
or  engineer  specified  algorithms,  involving  one  or  more 
telemetered  values.  These  calculated  variables  would 
become  a part  of  the  data  base  and  be  treated  by  all  other 
software  programs  as  though  they  were  remotely  acauired 
variables.  Both  continuous  and  discreet  calculated 
variables  should  be  provided.  Defining  algorithms  might 
consist  of  standard  functions  such  as  sums,  differences, 
averages,  integrations,  minimal,  or  special  calculations. 
The  following  special  calculations  should  be  provided 
initially  in  the  ECS. 

a.  Meter  Error  Analysis 

Data  from  tie  lines  and  metering  points  is  collected 
in  two  forms:  instantaneous  MW  readings  approximately 
every  two  seconds,  and  MWH  data  collected  every  hour. 
Control  is  based  on  the  two  second  MW  readings. 
Integration  of  these  readings  over  an  hourly  period 
should  provide  the  same  value  as  collected  via  the 
more  accurate  MWH  digital  telemetering . The  Meter 
Error  Analysis  program  will  monitor  the  readings  for 
integration  discrepancies  and  advise  the  System 
Dispatcher  of  the  immediate  correction  that  should 
be  made  to  reduce  erroneous  interchange.  All  metering 
errors  should  be  logged  for  use  by  maintenance  per- 
sonnel . 

b . MVA  Calculation 

MW  and  MVAR  data  will  be  telemetered  for  transformers, 
and  seme  transmission  lines.  The  computer  should 
calculate  the  MVA  flowing  on  these  devices  and  check 
the  results  against  limits  to  determine  overloads. 

6 . Data  Logging 

The  ECS  should  generate  as  many  of  the  required  formal 
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logs  as  possible.  Data  on  the  log  sheets  may  be  telemeter 
ed,  calculated, or  entered  manually  by  a System  Dispatcher 
Logs  should  print  their  own  column  and  rov  headings,  and 
not  require  preprinted  log  forms.  The  data  base  should  be 
used  to  supply  complete  and  accurate  historical  logs  -i. 
for  use  by  other  departments.  The  ECS  should  provide  a 
separate  facility  for  logging  status,  change-in-status, 
alarms  and  other  data.  The  system  should  also  provide  a 
hardcopy  log  on  the  alarm/events  printer  of  all  system 
dispatcher  control  actions,  limit  changes,  and  breaker 
tagging  operations.  This  hardcopy  chronological  history 
would  provide  a historical  record  useful  in  verifying  and 
re-evaluating  optimum  operating  practices.  Certain  logs 
would  occur  hourly,  others,  once  per  shift,  or  daily. 

The  System  Dispatcher  may  request  the  printing  of  any 
periodic  log.  The  contents  of  any  CRT  display  may  be 
logged  upon  System  Dispatcher  demand. 

T . Load  Management 

This  function  would  provide  the  System  Dispatcher  with  a 
CRT  display  of  the  schedule  of  loads  to  be  interrupted 
when  an  emergency  arises.  A CRT  display  will  provide  the 
interface  through  which  the  System  Dispatcher  may 
quickly  initiate  the  load  interruption  sequence.  Load 
interruption  points  may  be  multiple  breakers,  with  points 
within  a set  existing  at  separate  RTUs . 

As  an  option,  the  load  shedding  program  may  maintain  a 
record  of  all  actual  load  interruptions  so  that  they 
may  be  accomplished  on  an  equitable  basis.  During  a load 
interruption  period,  the  program  would  keep  track  of 
outage  times  and  alert  the  System  Dispatcher  when  it  is 
time  to  transfer  load  interruption  to  the  next  scheduled 
group.  Restoration  of  service  to  disconnected  loads  will 
be  done  on  an  individual  circuit  basis,  using  the 
standard  supervisory  control  functions. 

8 . System  Peak  Analysis 

Periodically,  this  program  should  calculate  the  instant- 
aneous and  hourly  system  loads.  As  new  peaks  are  achieved 
the  magnitude  of  the  peaks  and  associated  readings  should 
be  retained  in  long-term  historical  storage.  The  current 
daily  peak  to  date  should  be  available  upon  system  dis- 
patcher demand.  The  values  retained/logged  at  each  peak 
and  the  retention  period  for  the  storage  buffers  should 
be  under  programmer  or  engineer  control.  Separate  peak 
analyses  should  be  performed  for  the  total  system  load. 
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and  for  those  portions  of  the  load  distributed  to  other 
interconnected  utilities.  To  aid  in  billing  of  member 
cooperatives,  the  peak  hourly  load  in  a calendar  month, 
for  each  metering  point,  should  be  determined  and  retained 
for  an  adjustable  period. 

9 • Energy  Accounting 

The  telemetering  of  data  from  all  significant  loads  is 
necessary  to  meet  generation  control  obligation.  The 
hourly  MWH  and  MVARH  data  is  collected  from  these  loca-i 
tions  can  also  be  used  to  support  a variety  of  accounting 
functions,  specifically: 

° Daily  energy  logs : At  the  end  of  each  day  a 2h  hour 
log  should  be  prepared  showing  hourly  and  total 
energy  usage  and  interchanges  for  each  member  co- 
operative and  utility.  A system  dispatcher  should 
have  the  opportunity  to  review  and  edit  the  log  to 
account  for  known  telemetry  errors  and  to  supply 
data  for  non-telemetered  loads 

° Weekly  energy  logs:  At  the  end  of  each  week  a seven 
day  log  should  be  produced  showing  hourly  and  total 
energy  usage  and  interchanges  for  each  member  co- 
operative and  utility.  A system  dispatcher  should 
have  the  opportunity  to  review  and  edit  the  log  to 
account  for  known  telemetry  errors  and  to  supply 
data  for  non-telemetered  loads.  The  log  will  be  used 
to  conduct  weekly  metering  checks  where  required  by 
contract 

° Monthly  energy  accounts:  Each  mbnth,  the  hourly 
MWH  readings  for  each  metering  point  for  the  month 
should  be  output.  Totals  for  each  metering  point 
and  the  peak  MWH,  corresponding  MVARH  and  peak  MVARH 
should  also  be  provided.  Output  of  this  data  should 
be  printed  in  form  and  on  a machine  readable  medium 
such  as  magnetic  tape  for  possible  processing  by  an 
accountable  computer 

° Monthly  interchange  summary:  Tabulations  are  required 
of  all  interchanges  by  type  each  month  with  each 
interconnected  utility.  Inadvertent  interchange 
balances  should  also  be  shown  for  the  current  and 
previous  months 
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10 . Disturbance  Analysis 


The  analysis  of  a system  disturbance  should  be  segmented 
into  three  distinct  periods:  pre disturbance , disturb- 
ance, and  postdisturbance . The  start  of  a disturbance 
should  be  indicated  by  an  absolute  value  of  frequency,  a 
rate-of-change  of  frequency,  a prespecified  value  of  ACE 
and/or  net  interchange  duration,  of  by  preset  changes 
in  configuration.  The  disturbance  should  be  declared  over 
upon  restoration  to  normal  system  operating  values.  All 
events  denoting  the  beginning  and  ending  of  a disturbance 
should  be  under  programmer /engineer  control.  During  the 
three  periods  of  disturbance,  system  frequency,  load  and 
net  interchange,  unit  real  and  reactive  power,  real 
power  flow  on  selected  lines  and  transformers,  and  select- 
ed bus  voltages  should  be  collected.  The  program  should 
be  structured  to  allow  other  items  specified  by  the 
programmer  or  engineer  to  be  collected.  Software  programs 
should  be  provided  to  analyze  the  mass  of  data  collected, 
and  present  well  organized  displays  of  data  to  the 
engineer.  This  should  include  graphic  displays  on  CRTs, 
strip  chart  recorders,  and  hard-copy  logs.  The  ultimate 
goal  of  the  disturbance  analysis  package  should  be  to 
provide  sufficient  information  on  previous  disturbances 
to  enable  early  warning  and  prevention  of  future  dis- 
turbances . 

11.  Storage  and  Retrieval 

A storage  and  retrieval  program  should  periodically 
collect  and  store  data  as  specified  by  the  programmer 
or  engineer.  Data  may  be  telemetered  on  calculated 
values,  and  should  be  retained  in  circulating  buffers  in 
auxiliary  memory  for  prespecified  time  periods  (minimum 
of  30  hours).  The  retention  period  for  each  buffer  should 
be  independently  specified.  The  programmer  of  engineer 
should  have  the  capability  to  periodically  dump  the 
buffers  to  magnetic  tape  for  long  term  retention  of  the 
data.  Associated  programs  should  be  available  to  format 
and  display  these  variables  periodically,  at  a specified 
time  after  an  event,  or  upon  dispatcher  demand.  Display 
facilities  should  include  logging,  pen  recording,  and 
CRT  displays.  The  program  structure  should  be  modular  and 
allow  for  other  programs  of  this  type  to  be  added  at  a 
later  date.  One  program  for  retrieval  of  this  data  has 
been  identified  and  should  be  investigated  as  an  option 
in  the  specification.  Hourly  load  data  could  be  retrieved 
from  this  file  for  delivery  points.  This  data  could  be 
automatically  supplied  (at  the  system  dispatcher’s 
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discretion)  to  the  AGC  program  as  a substitute  for  failed 
telemetry  data  for  affected  metering  points. 

12.  Background  Facilities 

State-of-the-art  hardware  and  software  facilities  should 
be  provided  for  the  programmer  or  engineer  responsible 
for  maintaining  and  augmenting  the  system.  Provisions 
should  be  made  for  the  programmer  or  engineer  to 
assemble  or  compile  programs  utilizing  the  full  capabili- 
ties of  the  CRT.  The  programmer  or  engineer  should 
utilize  the  CRT  to  debug  new  programs  without  interfering 
with  or  endangering  the  normal  on-line  functions  of  the 
system.  The  programmer  or  engineer  should  be  capable  of 
utilizing  his  man /machine  interface  to  integrate  new 
programs  into  the  system  on-line . The  system  should 
include  assemblers  or  compilers  for  all  languages  used  by 
the  vendor  for  original  system  sofrware,  plus  diagnostic 
testing,  and  exercising  programs  to  periodically  examine 
the  status  of  as  many  peripherals  as  is  practicable,  with 
out  interfering  with  the  normal  operation  of  the  system. 
Provisions  should  be  included  for  the  creation  of  new 
CRT  displays  and  logs  and  for  the  editing  of  existing 
formats . 

13 • Dispatcher’s  Power  Flow 

A transmission  system  may  be  run  at  near  capacity 
levels.  As  the  transmission  network  becomes  more  complex, 
it  will  be  increasingly  difficult  for  a system  dispatcher 
to  determine  beforehand  the  results  of  various  switching 
operations.  The  dispatchers  need  to  know  this  type  of 
information,  however,  so  they  do  not  perform  switching 
that  jeopardizes  the  integrity  of  the  system.  This 
dispatch  function  can  prevent  overloads,  possibly  even 
prevent  service  interrruptions , and  certainly  makes  the 
dispatcher's  job  easier.  The  use  of  a power  flow 
program  at  an  off-line  console  as  a training  device  for 
new  dispatchers  will  provide  significant  savings  in  train 
ing  time  and  dollars  over  a very  short  period. 

lU.  Load  Forecasting 

Accurate  forecasting  of  electrical  demand  is  the  first 
step  in  scheduling  generation  interchange.  This  in- 
formation is  critical  to  the  generation  scheduling  in 
order  to  provide  the  smoothest,  most  economical  transi- 
tions between  daily  peak  and  low  demand  periods.  The 
weather  has  a major  effect  on  any  system  load  and  must  be 
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accounted  for  in  any  load  forecast  programs  considered. 
15 . Control  Center  Layout 

Figure  III-l  shows  a typical  layout  of  an  ECS  control 
center.  The  ECS  operators  use  man/machine  devices  to 
interface  with  and  operate  the  generation-transmission 
system  and  distribution  system.  Major  elements  which 
make  up  the  ECS  man /machine  subsystem  may  include: 

0 Power  console 

0 Transmission  console 

0 Programmer's  console 

0 Logging  printers 

0 Line  printers 

0 Magnetic  tape  units 

0 Video  hard  copy  device 

0 Card  reader 

0 Static  mapboard 

0 Chart  recorders 

0 Time  frequency  and  digital  display  panel 
0 ECS  status  and  configuration  panel 
a.  Consoles 


Two  control  consoles  may  be  provided.  A transmission 
console,  and  a power  (generation)  console,  each  so 
designed  that  the  ECS  can  be  fully  operated  from 
either.  Each  position  should  be  equipped  with  seven- 
color  CRT  display  monitors,  alphanumeric  and  special 
function  keyboards,  and  a light  pen.  Space  shall  be 
provided  for  radio  and  communications  turrets  on  each 
console.  Details  of  consoles  and  communications  will 
be  coordinated  with  the  Borrower  following  Vendor 
selection. 
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Figure  III-l  Conceptual  Control  Center  Space  Layout 


The  power  console  should  provide  the  required  facilities 
for  the  system  operator  to  monitor  and  control  pro- 
grams and  functions  associated  with  the  generation. 

The  console  will  normally  be  used  for  modification 
and  insertion  of  control  parameters,  substitution  of 
missing  data,  manual  execution  of  programs,  monitor- 
ing of  generating  facilities,  requesting  logs  and 
reports,  and  initiating  selected  programs  including 
load  scheduling  functions.  This  console  may  also  be 
used  for  other  general-purpose  dispatch  functions. 

The  transmission  console  should  provide  the  required 
facilities  for  the  system  operator  to  monitor  and 
control  the  bulk  transmission  network.  The  console 
will  normally  be  used  for  general  system  monitoring, 
supervisory  control,  and  equipment  tagging  and  re- 
lated orders  on  maintenance  and  emergency  outage 
dispatching.  This  console  may  also  be  used  for  other 
general  purpose  dispatch  functions. 

A single  position  programmer’s  console  may  also  be 
provided.  The  console  should  have  a seven  color  CRT 
display  monitor,  an  alphanumeric  keyboard,  a special 
function  keyboard,  and  a light  pen. 

The  programmer's  console  should  provide  the  capability 
for  generation  and  modification  of  CRT  images,  for 
modifications  to  the  system  data  base,  for  program 
developmemt , and  possibly  for  operator  training.  This 
console  shall  have  the  capability  of  being  independ- 
ently switched  between  the  on-line  processor  and  the 
backup  processor.  The  programmer’s  console  should 
interlocked  with  software  such  that  no  control  action 
or  replacement  of  real-time  data  may  occur  from  this 
position.  Secure  provisions  shall  be  provided  to 
unlock  this  console  in  the  event  it  is  required  for 
emergency  operations.  This  shouldbe  accomplished 
through  the  use  of  a software  key  which  would  make 
this  console  available  to  support  system  operations. 

In  this  event  it  shall  be  made  unavailable  to  pro- 
gramming functions. 

b . Logging  Printers 

Logging  printers  should  be  provided  which  are  central- 
ly located  with  respect  to  the  power  and  transmission 
consoles  such  that  they  can  be  easily  viewed  from 
either  operating  position.  One  -unit  will  normally  be 
utilized  for  alarm  logging  and  one  for  operator  action 
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logging.  A third  logger  will  be  located  in  the  vicini- 
ty of  the  programmer's  console.  All  logging  printers 
shall  be  functionally  interchangeable. 

c.  Line  Printers 


Line  printers,  if  provided,  should  be  associated  with 
each  computer.  These  units  will  be  located  in  the 
computer  room.  In  addition  to  serving  various  pro- 
gramming and  system  diagnostic  needs  they  will  be 
utilized  to  produce  a series  of  formatted  reports  on 
an  hourly,  daily,  weekly,  monthly,  or  demand  basis. 

d.  Magnetic  Tape  Units 

Magnetic  tape  units,  if  provided,  should  be 
capable  of  providing  the  following  functional  oper- 
ations : 

° Loading  of  programs  into  the  ECS 

° Receiving  copies  of  the  historical  data  file  on 
a periodic  basis 

° Support  of  engineering  studies 

° Support  of  program  development 

e . Video  Hard  Copy  Device 

A single  hard  copy  device  capable  of  producing  a 
facsimile  of  any  CRT  image,  less  color,  should  be  pro- 
vided. A video  actuated  device  or  character  printer 
with  a character  set  identical  to  the  CRT  display 
generator  character  set  are  acceptable  approaches.  An 
operator  should  have  the  capability  of  requesting  a 
hardcopy  of  any  image  from  any  operating  position. 

f.  Card  Reader 


A card  reader,  switchable  to  either  CPU,  may  be 
provided  for: 

° Data  base  and  CRT  picture  maintenance 

° Loading  of  programs  or  data  for  engineering 
studies,  etc. 
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g.  Mapboard 


A static  mapboard  panel  should  be  considered.  The 
graphics  on  the  board  would  allow  the  Borrower  to  show 
the  overall  transmission  and  generation  system  in 
simplified  form  and  permit  the  operators  to  view  the 
total  network.  Detailed  status  of  specific  stations 
will  be  obtained  from  CRT  displays. 

h . Time,  Frequency  and  Digital  Display  Panel 

The  ECS  should  have  a panel  which  contains  various 
displays  and  functions  associated  with  time,  fre- 
quency, backup  AGC  and  display  of  selected  system 
variables.  This  panel  will  house  several  digital 
displays  visible  from  at  least  twenty  feet  away  as 
follows : 

° System  time 

° Time  deviation 

° Frequency  deviation 

° Operator  selected  variable 

In  addition,  the  panel  should  house  backup  analog 
AGC  area  control  error  (ACE)  computation  equipment 
and  its  associated  controls  and  indications.  The 
ACE  chart  recorder  (Borrower  provided)  should  be 
located  on  the  chart  recorder  panel. 

i . ECS  Status  and  Configuration  Control 

A form  of  indication  control  shouldbe  provided  which 
permits  the  operator,  programmer,  or  maintenance 
engineer  to  determine  the  operational  status  and 
present  conf iguration  of  the  computer  systems,  peri- 
pherals, related  communication  channels  and  equipment. 
Control  capability  in  the  computer  room  should  be  pro- 
vided, which  permits  switching  of  certain  peripherals 
and  commnunication- devices  from  one  computer  to  the 
other,  and  to  allow  manually  initiated  failover.  The 
ECS  status  indication  and  control  functions  may  take 
the  form  of  a panel  in  the  computer  room  and  a CRT 
display  in  the  control  room. 


III-15 


1 6 . Digital  Communications  Channels 


Communi cat ions  with  the  RTUs  generally  use  half-duplex 
operation  over  U-wire  full-duplex  channels  operating  at 
1200  baud.  Whenever  possible,  RTUs  should  be  party-lined 
with  a maximum  of  six  RTUs  per  party-line.  The  Vendor 
should  provide  an  analysis  of  wordt  case  operational 
line  loading  considering  the  initial  and  maximum  fully 
expanded  number  of  points  from  each  RTU. 

The  secure  operation  of  the  power  system  is  of  prime  im- 
portance. Errors  in  data  transmission,  communication 
channel  noise,  and  dropouts,  shall  not  cause  any  improper 
power  system  control  actions.  The  ECS  computer  shall 
constantly  determine  the  integrity  of  the  commnuications 
system,  as  a minimum,  through  the  following  forms  of 
equipment  malfunction  and  error  detection: 

° Error  Detection  Codes  - Data  transmission  errors 
should  be  detedted  by  use  of  error  detection  codes 
imbedded  in  the  master  station-to-RTU  and  RTU-to- 
master  station  messages.  The  error  detection  codes 
may  be  BCH  of  geometric  codes.  An  RTU  receiving  a 
message  containing  a detected  error  shall  not  re- 
spond to  that  message.  The  master  station  receiving 
a message  having  an  error  detection  code  error 
shall  successively  reinterrogate  the  RTU  up  to  five 
times.  If  satisfactory  response  is  not  obtained,  the 
RTU  and/or  the  communications  channel  shall  be 
declared  to  have  failed  and  an  RTU/"channel  out" 
alarm  shall  be  set.  After  15  -minute  duration,  the 
master  station  should  retry  the  failed  channel  and 
determine  if  the  channel/RTU  is  usable  again.  Pro- 
visions for  tagging  the  channel/RTU  for  no  retry 
sha^l  be  provided. 

0 No  Reply  - If  a reply  is  not  received  from  an  RTU, 
the  ECS  computer  should  reinterrogate . If  after  five 
successive  retries  there  is  still  no  reply,  the  RTU 
and/or  the  communications  channel  shouldbe  declared 
to  have  failed  and  an  RTU/"channel  out"  alarm  should 
be  set.  After  15-  minute  duration,  the  master  station 
diould  retry  the  failed  channel  and  determine  if  the 
channel/RTU  is  usable  again.  Provisions  for  tagging 
the  channel/RTU  for  no  retry  shouldbe  provided. 


III-16 


° Wrong  Reply  - If  the  reply  from  an  RTU  is  incorrect 
in  address  or  function  code,  the  message  should  he 
ignored  and  the  RTU  re  interrogated.  If  after  five 
(or  other  selectable  value)  successive  unsuccessful 
retries  the  RTU  and/or  the  communications  channel 
should  be  declared  to  have  failed  and  an  RTU/"channel 
out”  alarm  shall  be  set.  After  15  minute  duration, 
the  master  station  should  retry  the  failed  channel 
and  determine  if  the  channel/RTU  is  usable  again. 
Provisions  for  tagging  the  channel/RTU  for  no  retry 
should  be  provided. 

° Error  Rate  - If  the  number  of  any  combination  of 
errors  detected  on  any  communication  channel  or 
from  any  RTU  exceeds  a specified  threshold  of  errors 
per  unit  time,  the  operator  should  receive  an  RTU/ 
"channel  degraded"  alarm. 

17.  System  Data  Scanning  Rates 

Power  system  data  should  be  brought  into  the  ECS  from  the 
RTUs  via  the  digital  communication  network  and  from  the 
local  data  acquisition  systems.  The  RTUs  are  under  the 
direct  control  of  the  system  computer  and  in  general,  the 
scanning  rates  are: 

0 Two-second  scan  - For  all  status  changes,  generator, 
and  tie  line  MW  and  MVAR  and  frequency  measurements 
including  local  analog  telemetry  channels 

0 Ten  second  scan  - For  all  other  transmission  line 
MW  and  MVAR,  volts,  transformer  bank  MW  and  MVA, 
etc . 

0 Ten-minute  scans-  For  weather  related  quantities 

- For  a system  data  base  update  of 
all  status  and  alarm  points 

0 Hourly  scan  - kWh  broadcast  freeze  and  quantities 

0 On  demand  - Any  of  the  above  data  group  selected  by 
operator 

0 Generation  Raise /Lower  - Corresponding  to  AGC  exe- 
cution cycle  ( about  once  every  two  to  eight  seconds) 

0 Supervisory  Control  - Arming  of  interposing  relay 
within  one  second  of  point  selected  on  the  CRT 
and  completion  of  control  action  within  one  second 
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bf  execution  command  entry  by  the  operator.  Master 
station  and  the  RTUs  should  have  independent  time- 
out counters  to  prevent  the  system  from  becoming 
locked-up  (10  to  30  seconds) 

° Demand  Input  - Capability  to  accept  unscheduled 
arrival  of  information  from  the  microwave  alarm 
system  and  the  master  station 

l8 . Local  Data  Input /Out out  Requirements 

Certain  data  will  be  either  input  or  output  to/from  the 
ECS.  These  will  include  analog  telemetry  interfaces  both 
in  and  out,  chart  recorder  drives,  status  inputs,  time 
and  frequency  transducer  interfaces,  digital  displays,  ECS 
teletype,  and  the  WWV  clock.  A possible  solution  for 
interfacing  some  of  these  data  is  to  utilize  a "LOCAL" 

RTU. 


19 • System  Sizing 

A paramount  objective  in  planning  and  designing  the  ECS  is 
to  assure  that  the  purchaser  will  not  be  constrained  by 
either  hardware  or  software  restrictions  that  prevent 
orderly  growth  over  the  next  decade . Each  part  of  the 
system  shall  be  examined  carefully  to  determine  how 
expansion  can  be  implemented  in  the  future.  Areas  of 
particular  importance  include  the: 

0 Data  base  design  and  main  memory  reserves  and  growth 

0 Data  acquisition  system 

0 Man/machine  system 

0 Computer  system  throughput 

0 Mass  memory  reserves  and  growth 

In  order  to  accomplish  expansion  of  change  in  an  orderly 
manner,  hardware  and  software  shouldbe  modularized.  The 
total  software  shouldbe  subdivided  into  many  smaller 
packages,  each  with  specific  functions,  clearly  defined 
external  boundaries,  and  relatively  simple  interfaces  to 
other  software  packages. 
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Serious  consideration  should  be  given  to  the  quality  and 
ease  of  operation  of  the  special  conversational/interac- 
tive compilers  used  for  generation  of  new  CRT  pictures 
and/or  expansion  of  the  data  base  as  new  points  and 
terminals  are  added  to  the  system.  The  vendors  should 
explain  in  detail  how  this  is  to  be  accomplished. 

The  selection  of  a computer  should  be  based  on  its  capabil- 
ity to  perform  all  the  functional  requirements  as  set  forth 
in  this  specification  while  retaining  adequate  reserve 
capability  for  future  growth  and  expansion.  Certain  mini- 
mal criteria  have  been  established  for  the  size  and 
capability  of  the  CPU,  the  main  memory,  and  the  mass 
memory.  These  requirements  are: 

° CPU  Throughput  - The  initial  system  CPU  should  be 
size  with  at  least  60%  unassigned  reserve  capacity 
in  processing  capability,  averaged  over  a 6C-  second 
time  period  during  the  worst  case  loading  condition 
(includes  all  required  application  programs) 

0 Main  Memory  - The  initial  system  main  memory  should 
average  at  least  25%  of  unassigned  reserve  core 

° Mass  Memory  - The  initial  system  mass  memory  should 
have  at  least  70%  of  its  capability  unassigned.  The 
disk  pack  shall  not  have  any  permanent  storage 
assignments 

° Backup  CPU  - The  backup  CPU  shouldbe  capable  of 
handling  a background  FORTRAN  program  of  at  least 
128k  words 

° Communications  Channels  - The  initial  communication 
I/O  channel  capacity  should  have  at  least  40%  reserve 
capability 
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B.  Hardware  Considerations 


This  section  prescribes  the  hardware  requirements  resulting 
from  the  functional  requirements  stated  in  previous  sections. 
Hardware  attributes  that  may  be  important  include: 

0 High  System  Availability  - By  providing  hardware  re- 
dundancy for  critical  system  functions,  including 
manual /automatic  switchover  capability  in  the  event 
of  failures 

° Real-Time  Computers  - To  perform  the  system  critical 
functions  such  as  data  communications,  man/machine 
functions,  data  logging,  and  automatic  generation 
control 

° Man/Machine  Equipment  - To  provide  an  efficient  inter- 
face between  the  operators  and  the  ECS 

° Maintainability  - To  be  designed  into  the  system  in 

terms  of  modularity,  special  test  points,  accessibility, 
and  special  test  equipment 

0 Future  Expansion  - To  be  designed  into  the  initial 
system  such  that  it  may  be  conveniently  expanded  as 
the  information  and  control  functional  requirements 
increase  and  change  over  the  years. 

Where  the  borrower  has  a preference  for  specific  hardware 
components,  the  manufacturer's  type  and  model  number  or 
approved  equal  should  be  specified.  If  the  vendor's  proposed 
configuration  does  not  make  use  of  the  listed  hardware 
components,  his  proposal  should  contain  additional  detailed 
descriptions  of  how  the  functional  performance  requirements 
of  the  specification  can  be  implemented. 

1 . Computer  Subsystem 

The  system  should  consist  of  two  identical  computers 
with  one  fully  capable  of  performing  all  system  on-line 
functions.  The  other  operating  in  the  standby  mode  with 
its  auxiliary  memory  periodically  updated  by  the  on-line 
machine. 

The  backup  machine  should  monitor  the  frequency  of  the 
data  transactions  and  automatically  assume  the  role  of 
the  on-line  machine  should  the  data  fail  to  arrive  on 
schedule  or  have  characteristics  indicating  a malfunc- 
tioning primary  machine.  Actual  transfer  should  occur 
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when  specified  interrupts  are  raised  between  the  two 
machines.  Computers  selected  for  this  application  must 
have  identical  characteristics,  with  emphasis  on  the 
following: 

° High  Availability 

° Hardware  and  software  designed  for  efficient  real- 
time operation 

° Flexibility  for  interfacing  to  a wide  variety  of 
external  devices  and  systems 

° Fully  designed  and  implemented  automatic  failover 
hardware 

° Capability  and  flexibility  for  expansion 

° High  performance  CPU  and  input /output  throughput 

All  computer  and  peripheral  devices  described  herein 
should  be  from  a standard  line  of  equipment,  manufactured 
and  supported  by  the  supplier . The  following  detailed 
specifications  are  for  the  purpose  of  identifying  a 
minimal  class  computer  system. 

a.  Central  Processing  Unit 

The  Central  Processing  Unit  (CPU)  should  be  selected 
so  that  the  on-line  machine  shall  have  sufficient 
computing  capability  to  support  the  total  program 
components  and  the  logic  operation  load  required 
for  the  supplied  hardware  and  software  system. 

The  CPU  should  perform  arithmetic  and  logical  opera- 
tions, control  the  on-line  machine,  execution  of 
instructions,  and  control  the  exchange  of  information 
between  the  memory  and  other  parts  of  the  system. 
Listed  below  are  characteristics  considered  accept- 
able for  each  CPU: 

° Word  Length  - A minimum  of  l6  information  bits 

° Memory  Addressing  - The  memory  should  be 
addressable  by  byte  and  word 

° Indirect  Addressing  - Each  CPU  should  have 
multilevel  indirect  addressing  allowable 
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° Immediate  Addressing  - Immediate  addressing  of 
operations  to  be  provided 

° General  Purpose  Registers  - A minimum  of  eight 
to  ten  addressable  general  purpose  registers 

° Index  Registers  - Two  to  four  general  purpose 
registers  may  be  used  as  index  registers 

0 Hardware  Mult iply /Divide  - The  central  process- 
or should  contain  arithmetic  and  control  logic 
for  performing  high  speed  fixed  point  arith- 
metic using  hardware  implemented  multiply  and 
divide  features 

0 Index  Formats  - Capability  for  indexing  memory 
addresses  by  bit,  byte,  and  word 

° Instruction  Set  - 96-word  instructions  minimum 

0 Bit  Manipulation  - A set  of  bit  manipulation 
instructions  are  necessary  to  enable  individual 
bits,  in  memory  to  be  tested  or  modified 

0 Floating  Point  Arithmetic  - Floating  point 
hardware  should  enable  the  computer  to  perform 
either  32-bit  or  6U-bit  floating  point  add, 
subtract,  multiply  and  divide  operations 

0 Machine  Traps  - Clearing  of  hardware  and  soft- 
ware operations  provided  by  traps  generated 
when  abnormal  conditions  occur 

0 Multiprogramming  - Hardware  and  software  fea- 
tures are  necessary  to  enable  multiple  programs 
to  time- share  computer  operation 

0 Real-Time  Clock  - A real-time  clock  and  inter- 
val timer  are  necessary  for  use  in  real-time 
system  control  and  time  allocation 

0 Hardware  Bootstrap  - A hardware  bootstrap  capa- 
bility to  allow  system  reload  from  disk  and 
magnetic  tape 

0 Control  Panel  - A control  panel  is  required  to 
provide  manual  computer  control.  Associated 
with  it  should  be  an  automatic  program  load 
feature  and  an  addressable  program  halt 
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feature  in  addition  to  all  necessary  controls 
and  displays  for  loading  and  displaying 
register  or  memory  content  and  for  performing 
all  required  control  functions 

0 System  Protect  - A system  protect  feature  is 
required  to  prevent  unauthorized  intervention 
with  computer  operation 

° Memory  Page  Protect  - A memory  page  protect 
feature  is  required  that  will  enable  the  privi- 
lege violation  trap  to  be  generated  if  the 
machine  is  operating  in  an  unprivileged  state 
and  attempts  execution  of  an  instruction  which 
modifies  the  contents  of  any  protected  memory 
location 

° Privileged  Operation  - A privileged  operation 
feature  is  desired  as  a safe-guard  against 
attempts  by  two  or  more  programs  to  use  the 
same  computer  resources. 

b . Direct  Memory  Input /Output  System 

A direct  memory  input/output  system  is  required  which 
enables  input  data  transfers  to  be  performed  inde- 
pendent of  the  internal  operation  of  the  machine. 

The  input /output  system  should  be  structured  to 
eliminate  central  processor  lockout  caused  by  peri- 
pheral device  response  time . The  CPU  should  initiate 
block  transfers  of  data  and  then  proceed  with  internal 
operation  while  the  transfers  occur  in  an  instantan- 
eous manner.  Data  block  transfers  should  be  made  up 
of  bytes,  or  words,  and  peripheral  devices  with  mini- 
mum data  rates  of  one  million  bits  per  second.  Out- 
put channels  should  be  completely  buffered  to  per- 
mit the  input /output  system  to  handle  high  speed 
single  peripheral  devices  or  a number  of  low  speed 
devices . 

c . Main  Memory 

Each  real-time  computer  provided  should  have  a private 
high  speed  main  memory  made  up  of  either  core  or  semi- 
conductor elements.  Required  characteristics  of  the 
main  memory  are  as  follows : 

° Capacity  - The  initial  main  memory  for  each 
machine  should  be  stuctured  for  the  requisite 
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number  of  words  and  expandable  in  a modular 
fashion 

° Cycle  Time  - One  microsecond  maximum  (word 
access ) 

° Word  Length /Parity  - It  is  desirable  that  for 
each  information  set  bit  stream  an  additional 
parity  bit  be  provided.  Parity  should  be 
automatically  generated  and  checked  on  each 
read  or  write  operation 

° Memory  Access  - Memory  should  be  supplied  which 
permits  direct  random  access  for  the  CPU  and 
the  I/O  system 

° Memory  Power  Supply  - If  a semiconductor  memory 
is  utilized,  a memory  battery  power  supply 
must  be  provided  to  save  the  memory  contents 
in  the  event  of  a power  interruption. 

d.  Mass  Memory 

Each  real-time  computer  should  be  provided  with 
rotating  disk  random-access  mass  storage  devices  with 
moving  re cording /playback  heads.  Under  normal 
operating  conditions  the  on-line  computer  updates 
the  disk  memories  on  both  computers  simultaneously 
with  system  data  base  parameter  changes.  The  path 
may  be  either  CPU-to-CPU  communications  channel,  or 
dual  ported  disks.  The  backup  computers  shall  have 
the  capability  of  updating  its  own  disk  memory  and 
obtaining  information  from  the  primary  or  on-line 
computer  disk  memory  from  priority  control  by  the 
primary  computer. 

e . Priority  Interrupt  System 

A priority  interrupt  system  should  be  provided  with 
individual  priority  levels,  each  with  a unique  loca- 
tion assigned  in  memory,  each  with  a unique  priority, 
and  each  capable  of  being  selectively  enabled  and 
disabled  under  program  control.  An  interrupt  priority 
structure  which  permits  an  interrupt  servicing 
routine  to  defer  a portion  of  processing  associated 
with  an  interrupt  level  by  first  processing  the  high 
priority  portions  of  the  routine  and  then  triggering 
a lower  priority  level  'is  desirable. 
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Priority  interrupts  are  basically  divided  into  two 
groups:  internal  in  ^rrupts  and  external  interrupts. 
The  internal  interruj.  r are  normally  associated  with 
the  CPU  and  I/O  system  perations  such  as: 

° Power  failsafe  processor  fault 

° Memory  fault 

° Input/output  data  transfer 
° Control  panel  interrupt 
° System  protect  interrupt 
° Program  traps 

External  interrupts  which  are  normally  assigned  to 
various  components  of  tb®  control  system,  such  as 
light  pen  selection  by  ■ operator  or  communications 
line  buffer  signals,  shot  have  the  capability  to 
place  each  external  inter:  ;n  one  of  the  following 

states : 

° Disarmed  - No  signal  to  that  interrupt  level  is 
admitted 

° Armed  - The  interrupt  level  can  accept  and  re- 
member an  interrupt  signal 

° Waiting  - A state  where  an  interrupt  signal  has 
been  received  and  is  waiting  to  be  advanced  to 
the  active  state 

° Active  - The  state  where  the  CPU  will  immedi-. 
ately  execute  the  control  of  the  assigned  in- 
terrupt location  of  the  next  instruction 

External  interrupts  should  be  identical  for  both 
computers.  One  external  interrupt  for  each  machine  is 
used  to  accomplish  primary /back up  computer  signaling. 

f . Computer  Console 

A computer  console  panel  which  permits  manual  control 
of  the  CPU  by  manipulation  of  toggle  switches  on  the 
face  of  the  panel  is  desirable.  Switches  should  be 
provided  which  permit  altering  the  content  of  the 
computer  memory  and  registers.  Visible  registers 
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which  permit  reading  the  content  of  selected  registers 
are  desirable.  This  panel  should  permit  programs  to 
be  started,  halted,  or  single-cycled.  The  computer 
should  permit  the  contents  of  memory  to  be  displayed, 
cleared,  and  loaded.  Indicators  that  permit  the 
computer  operator  to  monitor  the  status  of  the  various 
elements  of  the  computer  are  also  necessary. 

g .  CPU-to-CPU  Channel  Interface 


An  I/O  channel  between  the  two  CPUs  is  required  for 
high-speed  exchange  of  disk  update  between  the  on- 
line and  backup  machines  and  general  system  admini- 
strative messages.  The  high  speed  requirement  may  be 
waived  if  dual-ported  disk  controllers  are  to  be  used 
These  channel  devices  should  be  connected  through 
compatible  interfacing  equipment  to  assure  the  maxi- 
mum data  transfer  rate  is  achievable. 

h . Watchdog  Timers 

Watchdog  timers  effect  a failover  for  any  device  or 
software  routine  impairing  the  successful  operation 
of  any  critical  function. 

Watchdog  timers  should  be  purchased  as  part  of  the 
system.  These  may  be  part  of  the  CPUs  or  supplied 
externally.  Failure  of  the  on-line  machine  to  reset 
its  performance  monitoring  timer  within  a specified 
time  will  cause  the  system  to  failover  to  the  backup 
system. 

i . Computer  Keyboard/Printer 

Properly  interfaced  console  Keyboard-Send-Receive 
(KSR)  type  keyboard/printers  should  be  considered. 
These  devices  are  used  primarily  by  software  pro- 
grammers and  maintenance  personnel  in  program 
development,  maintenance  activities,  troubleshooting, 
system  cold  start  up,  etc.  The  devices  should  be 
interchangeable  with, and  the  same  manufacturer  type 
as  the  operator /alarm  loggers. 

j . Card  Reader 


A card  reader  with  associated  controller  should  be 
acquired  to  support  program  maintenance  and  back- 
ground processing.  This  unit  shall  be  manually 
switchable  to  either  computer. 
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k.  Magnetic  Tape  System 


Magnetic  tape  drive  units  with  associated  controllers 
should  be  considered.  The  tape  drives  are  used  in 
support  of  programming  operations  and  for  the  storage 
of  historical  information.  The  magnetic  tape  systems 
may  have  the  following  general  characteristics: 

° Tape  Size  - One-half  inch  by  732  meter  reels 

° Recording  Density  - 630  bits  per  cm  (phase 
encoded) 

° Recording  Format  - 9-track 

° Read/Write  Speed  - Tape  speed  of  1.1^3  meters 
second 

0 Error  Detection  - To  insure  data  recording 
accuracy,  the  magnetic  tape  system  should 
perform  read-after-write  check.  On  completion 
of  recording  the  tape  station  shall  receive  and 
record  both  the  cyclic  and  the  longitudinal 
redundancy  check  characters 

1.  Line  Printer 


Fully  buffered  line  printers  should  be  employed  in  the 
ECS.  One  printer  may  be  used  with  the  on-line  machine 
for  printout  of  scheduled  and  generated  reports.  The 
other  printer  would  be  normally  associated  with  the 
backup  machine  for  support  of  program  development, 
updating  and  modifications. 

m.  Power  Fail-Safe 

Each  real-time  computer  should  have  the  capability  to 
detect  the  imminent  failure  of  the  primary  AC  power, 
and  with  the  aid  of  a software  routine,  bring  an 
orderly  halt  to  computer  processing. 

Each  computer  should  continuously  monitor  the  pri- 
mary AC  power  line  voltage  and  if  a specified  drop 
in  line  voltage  is  detected,  the  computer  should  be 
interrupted  such  that  the  computer  initiates  a shut- 
down routine  to  store  the  contents  of  all  volatile 
registers  in  the  main  memory,  and  come  to  a halt 
condition.  The  subroutines  should  have,  as  a minimum, 
four  milliseconds  to  perform  all  necessary  functions. 
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During  this  period,  the  DC  power  required  to  operate 
the  CPU  and  main  memory  shall  be  maintained  by  the 
energy  stored  in  the  power  supply  filter  capacitors. 

As  the  primary  AC  power  is  brought  back  to  normal, 
the  power  fail-safe  feature  detects  the  condition 
and  again  notifies  the  computer  via  an  internal 
interrupt.  This  action  initiates  a startup  routine 
to  load  registers  with  data  stored  during  shutdown 
routine  and  resume  processing. 

n.  Floating  Point  Processor 

Each  computer  should  be  supplied  with  a floating 
point  processor  (FPP).  The  FPP  is  capable  of  high 
speed  floating  point  arithmetic.  It  should  provide 
for  a single-precision  (32-bit)  and  double  precision 
(64-bit)  operation.  The  system  should  be  able  to 
support  simultaneous  parallel  operation  with  the 
central  processor. 

o.  Data  Channel  Multiplexers 

Redundant  data  channel  multiplexers  should  be  pro- 
vided. This  equipment  must  be  capable  of  simultaneous 
data  transfer  between  the  interfacing  control 
computer  and  the  communication  data  channels. 

The  multiplexer  should  interface  with  the  standard 
computer  I/O  data  channel  and  be  capable  of  trans- 
ferring data  bi-directionally.  The  multiplexer  should 
provide  and  effective  data  link  between  the  computer 
memory  and  slow  devices,  such  as  loggers,  local  data 
conversion  equipment,  and  communication  data  channels 
operating  at  various  transmission  speeds. 

All  multiplexer  I/O  operations  should  be  program 
controlled;  once  data  transfer  program  is  initiated, 
the  multiplexer  should  totally  relieve  the  central 
processing  unit  from  the  details  relating  to  the  I/O 
transfer.  Data  transferred  between  any  of  the  multi- 
plexer ports  and  external  devices  should  be  complete- 
ly asynchronous  utilizing  a "hand-shake”  type  pro- 
tocol associated  with  the  various  peripheral  devices. 
Peripheral  devices  or  communication  data  channels 
should  notify  the  multiplexer  when  they  are  ready  by 
the  use  of  priority  structured  interrupt  channels . 
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p.  Data  Channel  Controller 


The  communication  channel  controllers  act  to  provide 
the  actual  communication  between  the  I/O  multiplexer 
and  external  devices  (RTUs  or  peripherals).  The 
controllers  provide  the  serial  to  parallel  data 
format  conversion  to  the  multiplexer  from  external 
devices,  and  the  parallel  to  serial  conversion  in 
the  opposite  direction.  Each  controller  should 
include  sufficient  buffering  to  accomodate  the  sub- 
stantial change  in  data  transfer  rates  through  it. 

Communication  data  channel  controllers  must  be  capable 
of  interfacing  to  communication  modems  operating  at 
rates  up  to  U800  baud,  or  interfacing  to  current 
line  drivers  for  operation  with  other  peripheral 
devices . 

q.  Communications  Switching 

The  control  system  should  provide  for  a communication 
switching  panel  arrangement  for: 

° Manual  - Rerouting  of  signals  at  both  the  analog 
and  digital  side  of  the  modems,  for  insertion 
of  test  equipment  leads,  or  for  miscellaneous 
communication  line /modem  switching 

° Patching  - Around  failed  modems  for  substitu- 
tion of  standby  modem 

° Monitoring  or  Testing  - Telephone  circuits  or 
data  channel  multiplexer /controller  interfaces 
without  interruption  of  on-line  traffic 

° Loop-back  Patching  - At  either  the  analog  or 
digital  side  of  the  modem,  either  toward  the 
data  channel  multiplexer /controller  interface 
or  toward  the  communication  circuits. 

The  communication  switching  panel  should  contain  pro- 
visions for  handling  all  analog  and  digital  circuits. 

2.  Remote  Terminal  Units  (RTUs) 

The  remote  equipment  supplied  for  a substation  or  power 
station  should  be  of  the  same  basic  design  and  functional 
capability  but  of  variable  configuration,  depending  on 
actual  point  counts  at  various  locations. 
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The  RTUs  may  be  furnished  in  several  sizes.  Each  size 
utilizes  the  same  basic  input/output  elements  but  may 
vary  in  quantities  of  internal  components:  card  files, 
power  supplies,  PC  cards,  wiring,  etc.  The  borrower 
should  determine  the  RTU  sizing  for  initial,  spare  and 
future  points. 

All  remotes  should  have  the  following  functional  capa- 
bilities : 

° Data  acquisition 
° Supervisory  control 

° Data  communication  and,  as  may  be  required, 

° Automatic  generation  control. 

a.  RTU  Expansion  Provisions 

Each  remote  terminal  unit  provided  should  be  con- 
figured to  accommodate  all  "initial"  and  "spare" 
points.  All  defined  "future"  points  should  be  imple- 
mented by  the  addition  of  plug-in  point  cards  and 
relays  only,  not  by  the  addition  of  common  logic, 
card  files,  power  supplies,  cabinets,  terminal  strips, 
and  the  like.  Power  supplies  and  cabinets  should  be 
sized  to  accommodate  initial,  spare  and  future  and 
an  additional  25-percent  capacity. 

b . Data  Acquisition 

The  remote  terminal  equipment  serves  as  the  main 
interface  between  the  power  system  and  the  ECS 
master  station.  The  power  system  input  signals  fall 
into  the  following  basic  categories: 

(l)  Analog  Inputs 

Analog  input  signals  are  defined  as:  "those 
variable  quantities  or  representation  of  inform- 
ation which  bear  an  exact  relationship  to  the 
original  variable." 

Standard  power  system  transducers  generally  will 
have  dc  current  output  ranging  from  0 - 1 ma 
into  a load  impedance  of  equal  to  or  less  than 
10k  ohms.  The  analog  inputs  should  be  ungrounded 
differential  type  inputs  such  that  two  RTUs  can 
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monitor  one  transducer  output.  The  vendor  should 
he  capable  of  supplying  adequate  signal  condi- 
tioning to  provide  suitable  interfaces  to  these 
and  other  analog  inputs.  Analog  conversion  and 
resolution  should  be  provided.  Common  mode  re- 
jection should  at  least  be  100  dB  at  60  Hz  and 
differential  mode  rejection  at  least  60  dB  at 
60  Hz. 

Each  analog  input  may  require  a surge  protector 
and  filtering  network  to  provide  protection 
against  high  voltage  transients  and  common  mode 
noise  signals.  Additional  filtering  networks 
should  be  used,  if  required,  to  minimize  sampling 
errors  based  upon  the  scan  time  requirements.  Two 
precision  voltages  should  be  provided  for  each 
analog-to-digital  conversion  (ADC)  as  calibration 
and  check  points  for  the  analog-to-digital  con- 
version . 

( 2)  Status/Alarm  Inputs 

The  remote  terminal  unit  status /alarm  input 
function  provides  the  capability  to  scan  status/ 
alarm  inputs  and  store  information  concerning 
the  current  status /alarm  state  and  changes  in 
the  state  that  occur  during  successive  £cans. 
Status  and  alarm  inputs  are  to  be  provided  from 
external  dry  contacts  either  Form  "A"  or  "B". 

Two  types  of  point  logic  are  required;  one  for 
indication  only  and  one  for  indication  plus 
transient  status  detection.  For  momentary  contact 
detection  (of  at  least  10  msec  duration)  status 
change  memory  capability  should  be  provided. 
External  contact  operation  may  be:  open  to  close, 
close  to  open,  momentary  close  or  momentary  open. 
The  RTU  should  not  reset  its  status  memory  bit 
until  it  receives  an  acknowledgement  from  the 
master  station  that  the  status  memory  data  has 
been  received. 

The  RTU  should  be  provided  with  separate  modules 
capable  of  accepting  and  accumulating  contact 
closures  from  kWh  meters.  The  accumulator  and 
buffer  registers  should  also  have  the  capability 
to  accumulate  and  store  at  least  12  binary  values. 
Separate  accumulators  may  be  used  for  monitoring 
kWh  "IN"  and  "OUT"  values.  The  accumulator  should 
be  capable  of  operation  from  2-wire  Form  A or  B 
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type  contact  and  from  3-wire  Form  C type  anti- 
bounce contacts. 

The  contents  of  the  kWh  accumulator  are  trans- 
ferred to  a buffer  register  upon  receipt  of  a 
freeze  command.  In  most  RTU  locations  the  freeze 
command  will  come  from  the  master.  In  seme  in- 
stances the  freeze  command  may  be  initiated  by  a 
contact  closure  in  kWh  accumulation  equipment. 
Whereas  in  other  instances  the  remote  will  produce 
a contact  closure  concurrent  with  its  receipt 
of  a freeze  command  from  the  master,  to  remotely 
freeze  the  accumulator  in  the  kWh  equipment. 

To  facilitate  interchangeability,  each  remote 
having  kWh  accumulators  and  located  at  an  inter- 
tie point  should  be  equipped  such  that  it  can 
either  accept  a local  freeze  command  in  the  form 
of  a contact  closure  from  a foreign  remote.  Sub- 
sequent to  receipt  of  the  freeze  command  by 
either  source,  the  data  in  the  accumulator  should 
be  buffered  out  and  the  RTU  accumulator  should 
continue  to  count.  The  buffer  register  should 
remain  unchanged  until  filled  with  new  data  upon 
receipt  of  the  next  freeze  command.  The  buffer 
shall  be  readable  by  the  master  station  at  any 
time  and  as  many  times  as  required  by  the  data 
acquisition  programs. 

Contact  closure  inputs  should  be  isolated  and 
filtered  for  surge  and  transient  protection  to 
avoid  multiple  counts  due  to  contact  bounce. 

c . Control  Outputs 

The  remote  terminal  units  provide  the  capability  to 
control  interposing  relays  upon  command  from  the 
control  center  for  supervisory  control.  Interposing 
relays  (IPR)  should  be  provided  for  breaker  and  other 
momentary  contact  closure  type  operations.  Latching 
type  IPRs  shall  be  available  if  required.  The  signal 
from  thd  master  station  closes  the  relay  and  a sub- 
sequent signal  releases  the  relay. 

A remote  terminal  unit  used  for  automatic  generation 
control  should  provide  the  capability  to  operate 
interposing  relays  for  governor  motor  actuator 
raise  or  lower.  A generation  control  output  command 
operates  in  the  immediate  execution  mode  with  an 
acknowledgement  message  sent  to  the  computer  based 
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control  equipment. 


d.  Local/Remote  Indicator 


Each  Remote  Terminal  Unit  should  he  equipped  with  a 
Local/Remote  switch.  With  the  manual  switch  in  LOCAL 
position,  all  data  acquisition  functions  are  avail- 
able at  the  control  center;  the  supervisory  control 
functions  are  then  available  for  test  purposes  only, 
and  no  operation  of  the  power  system  devices  may  take 
the  place  from  the  control  center.  A status  indica-. 
tion  that  the  RTU  has  been  transferred  to  LOCAL  mode 
when  the  manual  transfer  switch  is  set  to  LOCAL 
position  is  available  at  the  control  center. 

In  the  REMOTE  position  the  RTU  provides  for  data 
acquisition,  supervisory  control  and  system  routine 
test  functions. 

e . RTU  Power  Supply 

The  vendor  should  provide  adequate  protection  for  the 
RTU  equipment  from  voltage  transients  as  a result  of 
switching,  or  other  devices  which  may  derive  power 
from  the  same  battery.  .Similarly,  normal  operation 
of  the  RTU  should  not  introduce  into  battery  power 
supply  any  transient  greater  than  0.75  volt  peak-to- 
peak . 

3.  WWV  Time  Synchronizer /Receiver 


If  a WWV/WWVB  time  and  data  synchronizer  for  receiving 
NBS  radio  station  time  and  date  codes  is  to  be  provided, 
the  unit  should  have  the  following  minimal  features: 


° Automatic  on-time  synchronization  with  NBS  radio 
station  WWV/WWVB 

0 Self  contained  WWV/WWVB  receiver 

° Propogation  compensation  of  a transmission  delay 

° Internal  oscillator  for  continuous  operation  (sta- 
bility of  +1  x 10  ^ per  week) 

° Appropriate  interface  for  operation  with  the  master 
station  computers. 
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C.  Software  Design 


The  software  development  cycle  consists  of  three  parts: 
analysis  and  design;  coding  and  debugging;  checkout  and 
test . 

Analysis  and  design  is  the  most  important  phase  of  soft- 
ware development  and  should  be  carried  out  as  thoroughly 
as  possible.  Problems  in  coding,  debugging,  checkout  and 
testing,  and  in  maintenance,  are  largely  attributable  to 
a poor  analysis  and  design.  This  initial  phase  of  software 
development  specifies  the  individual  program  modules,  the 
inputs,  outputs,  tables  used,  tables  updated,  and  the  al- 
gorithms. Design  decisions  are  made  on  the  database  structure 
and  access  method,  table  and  file  structures,  data  update 
requirements,  and  backup  requirements.  All  hardware-to- 
software  and  sof tware-to-sof tware  interfaces  are  spelled 
out.  Initialization  procedures,  CRT  and  logger  messages, 
maintenance  requirements,  test  procedures,  and  acceptance 
criteria  are  all  specified.  All  this  must  be  done,  reviewed, 
and  agreed  upon  before  one  line  of  code  is  put  on  paper. 

All  too  often  the  natural  tendency  to  get  going  and  start 
coding  gets  the  better  of  the  software  designers  and  the 
analysis  and  design  effort  gets  hurried  through.  This  is  an 
invitation  to  disaster. 

The  coding  and  debugging  phase  typically  should  take  less 
than  25  percent  of  the  entire  software  development  work. 

Most  of  the  real-time  application  software  for  control 
centers  have  been  written  in  assembly  language.  However,  the 
capabilities  of  FORTRAN  for  real-time  use  have  improved  and 
there  is  a growing  trend  toward  more  use  of  this  language. 
Whatever  language  is  used  careful  attention  must  be  given  to 
those  program  features  which  affect  real-time  linkages, 
response  times,  and  program  reliability. 

The  real-time  linkages  of  a program  consist  of:  accesses 

to  the  database;  I/O  requests  to  use  and/or  update  files; 

I/O  requests  for  CRT  display  and  logger  messages;  program 
execution  requests.  Good  response  means  an  efficient  code, 
a minimum  I/O,  effective  use  of  subroutines,  and  proper  use 
of  interrupt  control  program  reliability  means  use  of  fail- 
safe logic,  proper  initialization  on  system  startup,  evidence 
of  timing  problems,  invulnerability  to  bad  parameters,  control 
of  possible  arithmetic  overflow,  and  proper  handling  of  error 
returns  on  I/O  and  program  execution  requests. 

The  checkout  and  test  phase  takes  up  the  rest  of  the  software 
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development  work.  The  individual  program  is  tested  in  the 
foreground  in  as  complete  a real-time  environment  as  possible. 
The  real-time  environment  is  built  up  gradually  as  each  pro- 
gram is  integrated  into  the  system.  When  the  entire  system 
is  put  together,  hardware  and  software,  the  individual  pro- 
gram tests  are  repeated  as  -part  of  the  system  checkout.  The 
acceptance  tests  complete  the  test  cycle.  The  test  drivers 
written  for  the  individual  program  tests  are  kept  for  later 
use  in  system  maintenance. 

1 . General 


The  vendor  is  responsible  for  providing  software  in  an 
operational  ready  state.  System  performance  should 
be  fully  demonstrated  as  a condition  for  final  acceptance 
in  accordance  with  software  design  requirements  mutually 
agreed  to  between  the  Borrower  and  Vendor.  If  possible, 
and  whenever  practical,  the  Borrower  should  use  the 
Vendor's  standard  program  packages. 

Successful  implemenation  of  the  software  requirements 
includes : 

° Identification  of  specific  programs  and  files  and 
their  organization  necessary  to  satisfy  the  require- 
ments of  the  specification 

° Design,  coding,  debugging,  and  documentation  of 
individual  programs 

0 Integration  of  all  programs  into  an  effective  and 
efficient  software  system 

° Demonstrate  by  test  of  overall  system  performance 
against  the  requirements  of  the  specification 

Main  and  memory  maps  and  program  run  times  which  show 
the  allotments  for  all  individual  programs  and  data 
files  required  to  meet  this  specification  should  be 
obtained  from  the  vendor. 

The  software  requirements  discussed  herein  are  for  the 
following  major  categories: 

0 The  operating  system 

° System  software 

° Application  software 
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° Programmer ’ s aids 

The  operating  system,  provided  by  the  computer  supplier 
performs  a variety  of  tasks,  including: 

° Scheduling  and  performing  I/O  functions 

° Interpreting  operator  or  other  input  commands 
for  specific  tasks 

° Scheduling  and  allocating  tasks 

° On-line  and  off-line  debugging  and  diagnostic  services 

The  control  and  or  energy  management  system  software 
provided  by  the  control  or  energy  management  system  Vendor 
consists  of  the  following  program  categories: 

° Data  communication  control 

° Man-machine  programs  for  CRT  displays,  console  controls, 
logger  printers 

° Special  handlers  required  for  external  interfaces  not 
standard  with  computer  supplier 

° Special  scheduling  services  for  power  application 
programs 

The  software  systems  provided  should  be  designed  and 
implemented  in  accordance  with  the  following  general 
guidelines: 

° The  overall  software  shall  be  responsive  to  the  system 
operational  and  functional  requirements 

° The  software  design  should  not  require  basic  modifica- 
tions to  the  computer  manufacturer's  operating  system 

° Straightforward  interfaces  should  be  established 
between  the  applications  programs,  the  operating 
system,  its  enhancements,  and  the  data  base 

° A well-structured  data  base  shall  be  provided  with 

associated  manufacturer's  features  which  are  independent 
of  display  and  application  programs 
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° All  software  shall  be  designed  with  a high  degree 
of  modularity  and  minimize  impact  of  future  changes 
and  will  simplify  test  and  evaluation  routines. 

° Use  of  the  Vendor’s  software  which  has  previously 
been  utilized  on  other  projects  is  encouraged  to 
minimize  cost  and  risk. 

0 The  software  shall  be  designed  so  that  it  is  not 
necessary  to  reassemble  or  recompile  the  system  in 
order  to  accommodate  clearly  anticipated  system 
growth . 

° Adaptability  for  expansion  to  accommodate  normal  changes 
should  be  based  on  the  concept  that  the  number  of  para- 
meters, the  location  of  parameters,  the  processing  given 
each  parameter,  and  the  display  list  be  under  data 
base  management  control. 

° System  software  may  be  written  in  assembly  language; 
however,  the  purchaser  prefers  all  applications  to 
be  written  in  FORTRAN.  Bidder  shall  state  what  language 
programs  are  written  in. 

If  the  system  procured  consists  of  dual  computers  and  their 
associated  peripheral  devices,  communications  and  man- 
machine  interfaces,  the  two  processors  shall  be  identical 
to  each  other  with  their  roles  reversible  at  any  time. 

In  normal  operation  one  of  the  processors  shall  perform 
all  system  functions  and  the  other  processor  shall  be  a 
backup.  Certain  functions,  such  as  program  development 
and  program  compilation,  may  occur  on-line  using  the  backup 
machine.  A summary  of  functions  for  the  two  processors  is 
provided  below: 

Primary  machine 


° Provides  all  external  communications  control  for 
electric  system  remote  terminals  and  local  data 
conversion 

° Provides  communication  to  all  man-machine  devices 

o Performs  application  programs  on  schedule  or  on  demand 

° Provides  a copy  of  control  system  data  on  a periodic 
basis  to  the  backup  machine  in  the  event  the  primary 
machine  should  fail 


III- 37 


Backup  machine 


° Provides  immediate  backup  to  the  primary  machine 
in  the  event  the  primary  machine  fails 

° Periodically  tests  the  primary  machine  for  normal 
operation 

0 Provides  processing  resources  for  program  development 
and  program  compilation 

2 . The  Operating  bystem 

The  basic  operating  system  is  one  which  is  provided  by  the 
computer  manufacturer  and  is  a fully  supported  programming 
system.  It  is  recognized  that  required  enhancements  are 
generally  provided  by  the  control  system  vendor;  however, 
these  enhancements  should  not  invalidate  future  support  of  the 
operating  system  from  the  computer  supplier. 

a . General  Requirements 

An  operating  system  is  provided  with  each  processor  which 
monitors  and  manages  the  allocation  and  use  of  the  indi- 
vidual processor  resources  and  the  combined  requirements 
of  a dual  system. 

The  operating  system  is  generally  interrupt/event  driven 
and  capable  of  multi-programming.  Several  main  memory 
resident  programs  and  several  non-resident  programs  should 
be  able  to  run  concurrently  with  a background  program  with 
emphasis  on  protected  foreground  operations.  The  operating 
system  should  take  maximum  advantage  of  secondary  disk 
storage  to  ensure  efficient  monitor  and  user  operations. 

The  disk  shall  be  used  for  storage  of  overlay  portions 
of  monitor  and  system  processors,  thus  minimizing  utilization 
of  main  memory.  Storage  areas  for  service  programs, 
processors,  libraries,  and  user  programs  shall  be  available 
on  the  disk.  Among  the  main  functions  of  the  operating 
system  are: 

° Control  overall  system  resources  and  prevent  two  or  more 
programs  from  simultaneously  accessing  the  same  resource 

° Permit  new  programs  to  be  added  and  tied  into  automatic 
scheduling  with  a minimum  of  effort 

0 Provide  I/O  handlers  for  all  standard  and  non-standard 
interfaces 
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0 Process  all  requests  for  program  execution  based  on 
external  or  interrupt  events 

° Schedule  programs  on  a priority  basis  and  assure  that 
no  program  execution  will  be  unreasonably  delayed 

° Provide  FORTRAN  interfaces  with  all  external  devices 

° Pass  parameters  to  a requested  program  via  main  memory 
or  disk  storage 

Request  other  programs  periodically  or  on  demand 

° Transfer  critical  portions  of  the  data  base  to  the 
backup  system  on  a periodic  basis 

° Perform  diagnostic  checks,  automatic  failover,  and 
automatic  restart 

9 Convert  data  from  one  format  to  another 

0 Handle  unsolicited  I/O  interrupts  from  the  operator 
or  other  programs 

0 Provide  re-entrant  service  functions  to  perform  I/O 
and  other  functions 

0 Provide  protection  of  programs  and  data  files  against 
inadvertent  or  unauthorized  modification 

° Provide  services  for  system  generation 
b.  Real-time  Scheduler 


A Real-Time-Scheduler  should  be  provided  which  regulates 
the  processing  of  system  and  application  programs.  The 
scheduler  performs  the  following  basic  functions: 

0 Initiate  task  execution  for  cyclic  programs 

° Initiate  tasks  resulting  from  the  occurrence  of  events 
for  specified  conditions  of  the  power  system 

° Initiate  tasks  resulting  from  operator  requests  or 
actions 

Capability  shall  be  provided  to  schedule  cyclic  programs 
at  any  time  within  a 24-hour  period  with  a resolution  of 
one  second.  The  system  should  provide  a calendar  time 
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program  that  provides  the  date,  hour,  minute,  and 
seconds  for  display  and  program  scheduling.  Time 
adjustments  for  local  standard  and  daylight  savings 
time  should  be  easily  accomplished  by  the  operator 
and  automatically  referenced  to  an  external  WWV  signal. 
Following  a system  restart,  the  system  clock  should 
automatically  reset  to  the  correct  local  load  time  as 
synchronized  with  WWV. 

c . Program  Security 

The  operating  system  ensures  the  protection  of  all  data 
files  against  inadvertent  or  unauthorized  modification. 

In  addition,  a procedure  shall  be  provided  to  restore 
system  files  and  ensure  fast  recovery  in  the  event  of 
hardware  failures.  The  backup  disk  must  contain  a 
subset  of  information  contained  on  the  on-line  disk. 

Mass  storage  files  should  be  updated  as  soon  as  system 
parameter  changes  are  received  or  historical  data  are 
retrieved  or  calculated.  Data  base  transfers  to  the 
backup  disk  occur  from  either  CPU  and  are  capable  of 
being  transmitted  to  the  other  CPU  for  file  update. 

d . System  Surveillance  and  Failover 

The  operating  system  monitors  an  array  which  contains 
information  concerning  the  computer  configuration. 

This  information  is  used  when  initiating  processes  and 
to  determine  when  degraded  conditions  exist.  The  operating 
system  should  contain  an  equipment  status  update  program 
for  the  purpose  of  declaring  whether  a device  is  either 
up  or  down. 

A number  of  different  failure  modes  are  possible  in 
systems  of  this  type.  Not  all  failures  will  justify 
a complete  switchover  to  the  backup  system  as  some  will 
only  cause  alarms  to  the  operator.  Several  failure 
modes  are  described  with  the  preferred  action  resulting 
from  each: 

° Critical  Device  Failure  - When  a critical  device  such 
as  the  mass  storage  unit  on  the  primary  system  fails, 
a full  failover  to  the  backup  machine  is  required. 

Such  failures  should  cause  an  alarm  and  be  logged 
out  on  an  alarm  logger. 

° Non-critical  Device  Failure  - When  a non-critical 

device,  such  as  a magnetic  tape  transport,  card  reader, 
or  printer  should  fail,  no  master  failover  sequence 
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is  desired.  Such  failures  should  cause  an  alarm  and 
be  logged  on  an  alarm  logger. 

° Software  Switchable  Device  Failure  - With  some  system 
configurations  certain  hardware  failures  can  be  cir- 
cumvented without  overall  system  switchover  by  switching 
to  an  alternate  device  via  program  control.  In  the  event 
of  a failure  of  a particular  device,  an  alternate  device 
may  be  brought  into  service  under  program  control  without 
a complete  system  failover.  In  the  event  this  occurs, 
an  alarm  is  raised . 

° Other  Failure  Conditions  - Whenever  processor  fault 

occurs  in  the  primary  machine  a master  failover  occurs. 
The  failure  causes  an  alarm  and  is  logged  on  an  alarm 
logger. 

e . I/O  Control  and  Processing 

Both  standard  and  special  I/O  drivers  and  handlers  shall 
be  provided  for  communication  with  all  external  devices. 

The  processing  requirement  to  service  these  handlers  and 
drivers  should  be  minimized.  All  I/O  processing  shall 
provide  for  error  checking,  buffering,  and  format  control. 

f.  System  Initialization  and  Restart 

An  initialization  module  should  provide  for  all  necessary 
information  for  system  initialization.  Included  in  this 
process  is  table  initialization  for  the  total  system 
followed  by  a call-in  of  permanent  processes.  A restart 
module  automatically  initiates  the  required  action  and 
restarts  the  system. 

Subsequent  to  any  system  outage  and  system  restart  where 
the  system  (time)  clock  may  have  been  altered,  the  into  nal 
time  clock  automatically  resets  to  the  time  receiver. 

3.  Communications  Software 


Software  is  required  to  support  message  exchange  for  all  scan 
modes,  generate  the  necessary  commands  to  retrieve  power  system 
data  and  status  information,  and  perform  the  requried  error 
and  reasonability  limit  checking  to  insure  the  validity  of 
the  received  information. 

a . Data  Scanning  and  Security  Checking 

Received  data  is  to  be  checked  against  reasonableness  and 
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operational  limits  and  all  bad  data  flagged  and 
alarmed.  Scalar  quantities  are  converted  to  engineering 
units,  the  real-time  data  base  updated  at  appropriate 
intervals,  and  status  information  examined  for  alarms. 

The  operator  should  be  able  to  inhibit  the  update  of 
any  selected  quantity  in  the  real-time  data  base  and 
to  substitute  a manually-entered  value  if  desired. 

A periodic  diagnostic  check  or  malfunction  detection 
scheme  should  be  provided  for  all  channel  adapter/ 
modem  combinations.  In  the  event  of  malfunctioning 
units,  a method  should  be  provided  to  allow  simple  or 
automatic  by-pass  reassignment  to  the  standby  units. 

The  automatic  detection  of  a defective  unit  raises 
an  alarm. 

Communication  system  alarms  accumulate  in  the  alarm 
file  for  subsequent  logging  and  display.  These  alarms 
include  but  are  not  necessarily  limited  to: 

° Excessive  rate  or  total  count  of  detected  trans- 
mission errors 

° Failure  of  an  RTU  to  respond 

° Failure  of  channel  adapter  or  modem 

The  message  structure  from  master  to  remote  and  remote 
to  master  must  have  the  same  level  of  security.  Security 
coding  and  decoding  shall  not  be  performed  in  the  main 
processor  unit . 

b . Data  Conversion  and  Limit  Checking 

Each  type  of  information  obtained  by  the  master 
station  shall  be  grouped  according  to  source  or 
function  such  as  station,  kWh  intertie  quantities, 
etc.  For  each  group,  unique  table-driven  logic  is 
provided  which  permits  conversion  and  limit  checking 
of  the  measured  quantities  or  status.  Typical  infor- 
mation or  processes  associated  with  these  data  include 
operational  limits,  reasonability  limits,  measurement 
type,  data  identification,  conversion  factors, 
position  in  group,  etc.  The  programming  provides 
at  least  the  following  functions: 

Operational  Limit  Checks  - Performed  on  all  incoming 
telemetered  measurements.  The  operational  limits 
consist  of  a high  and  low  value  entered  by  the  operator. 
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Reasonableness  Checks  - Performed  on  all  tele- 
metered measurements  which  fail  the  operational 
limit  check.  In  addition,  reasonableness  checks 
are  performed  on  all  manually-entered  data  at  time 
of  entry.  Reasonableness  limits  will  normally 
bound  the  maximum  possible  range  of  each  measurement . 
Should  the  reasonableness  check  fail  or  if  a syntax 
error  is  detected,  an  additional  bit  is  set  in  the 
real-time  data  base.  The  setting  of  the  failed 
reasonableness  check  from  a manual  entry  causes  an 
error  message  or  invalid  entry  announcement  to  be 
presented  to  the  operator.  The  bit  is  reset  by  the 
operator  clearing  the  entry.  If  the  bit  is  set 
because  a telemetered  value  failed  a check,  the  bit 
causes  an  alarm  to  be  presented  to  the  operator. 

Return  to  normal  range  resets  the  bit.  The  magnitudes 
and  sign  of  the  reasonability  checks  are  independent 
of  the  operational  limit  check  magnitudes  and  signs 
with  the  exception  that  reasonability  limits  should 
always  be  greater  than  the  operational  limits. 

Data  Scaling  Factors  - Provide  for  conversion  of  raw 
data  to  engineering  units. 

c . Data  Processing 

Capability  can  be  provided  for  the  operator  to 
interactively  create  computed  digital  data  points 
from  other  data  residing  in  the  data  base.  These 
points  are  then  available  the  same  as  any  other 
points  in  the  data  base.  The  following  operations 
should  be  available  as  a minimum  for  operation 
on  analog  data: 

0 Sum 

° Difference 
0 Product 
° Quotient 
0 Square 
0 Square  Root 

0 Maximum  value  and  time  (hourly  and  daily) 

0 Minimum  value  and  time  (hourly  and  daily) 
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The  following  logic  operations  should  be  available  as  a 
minimum  for  operation  on  discrete  data: 

° Or 

0 And 

° Exclusive  or 

The  processing  interval  for  data  computed  points  should 
be  initially  selectable  from  either  of  two  values.  One 
should  be  every  scan  time,  and  the  other  should  be 
approximately  once  every  30  seconds . The  calculated 
data  shall  have  the  quality  characteristics  of  the  least 
credible  data  used  in  the  calculation. 

d.  Local  Data  Interface 

In  addition  to  acquiring  data  via  RTUs , certain  data  may 
be  acquired  locally  from  analog  tone  channel  receivers, 
master,  local  status,  microwave  alarm,  etc.  Local  outputs 
are  provided  for  chart  recorder  driving  and  for  drive 
of  several  panel -mounted  digital  readout  devices. 

(1)  Analog  Data  Acquisition 

Certain  data  acquired  via  tone  channels  and  used 
for  chart  recorder  driving  may  be  acquired  locally, 
converted  and  entered  into  the  ECS  data  base.  The 
necessary  communication  handlers  shall  be  provided 
for  acquiring  local  analog  quantities  at  two  second 
intervals . 

(2)  Digital  Display  Drive 

Software  is  provided  for  driving  digital  display 
devices  mounted  on  the  chart  recorder  panel.  The 
operator  should  have  the  capability  of  assigning 
any  of  these  devices  to  any  real-time  or  computed  val- 
ue available  in  the  data  base,  scaled  or  unsealed, 
through  an  interactive  CRT  display. 

( 3 ) Chart  Recorder  Interface 


Software  is  provided  for  driving  the  chart  recorder 
channels.  Several  channels  should  be  assignable  by 
the  operator  via  an  interactive  CRT  display  to  any 
quantity  in  the  data  base.  Scaling  shall  normally  be 
set  to  utilize  recorder  full  scale.  In  addition. 
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scaling  in  the  form  of  ax+b  shall  be  assignable 
to  each  channel  by  the  operator.  Each  channel 
shall  be  updated  once  per  ten  seconds. 

The  balance  of  the  chart  recorder  driver  channels 
should  have  the  same  basic  attributes  as  the  oper- 
ator assignable  channels  except  that  the  assign- 
ments may  be  made  by  a programmer. 

( h)  Microwave  System  Alarms 


A software  system  may  be  provided  for  accepting 
and  processing  alarms  originating  from  as  ex- 
ternal microwave  alarm  monitoring  system.  Micro- 
wave  alarms  will  be  received  in  the  form  of  a 
serial  string  of  ASCII  characters  when  alarms 
occur.  Processing  and  display  of  microwave  alarms 
shall  be  consistent  with  the  overall  system  alarm 
requirements. 

U.  System  Data  Base 

A structured  data  base  should  be  provided  which  is  the  com- 
mon interface  between  the  data  acquisition  functions  and 
all  user  programs  including  displays,  logs,  reports,  and 
application  programs.  Functionally,  the  data  base  consists 
of  at  least  nine  separate  parts  as  follows: 

° Real-time  data  base  (including  pseudo  and  silent 
points ) 

° System  parameter  data  base 
° Results  file 
0 History  file 
° Alarm  file 

° Off-normal  status  file 
° Substation  action  file 
° Disturbance  file 
° Real-time  data  base  dump 
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The  system  data  base  generally  contains  all  information 
required  by  the  user  programs.  The  overall-  data  base  is 
initially  sized  to  accommodate  all  real-time  data. 

a.  Data  Usage  and  Coding 

A number  of  coding  indications  should  be  provided  in 
the  data  base  for  each  real-time  data  point.  The 
coding  should  indicate  to  using  programs  special 
conditions  which  apply  to  a given  data  point.  The 
following  conditions  for  coding  indications  are 
considered  minimum: 

0 Analog  value 

° Analog  value 

° Analog  value 

° Analog  value 

° Analog  value 

° Analog  value 

° Analog  value 

° Analog  value 
exceeded 

° Analog  value 
exceeded 

° Analog  scaling  factor  and  offset 
° Status  point  normal  state 
0 Status  point  in  off-normal  state 
° Alarm  classification  (critical,  non-critic.al) 
° Unacknowledged  alarm 

° Point  taken  out  of  scan  (by  operator) 

° Alarm  is  inhibited 
° Data  is  manually  substituted  value 


or  status  point  condition 
high  operational  limit 
low  operational  limit 
high  operational  limit  exceeded 
low  operational  limit  exceeded 
low  out  of  reasonability  limit 
high  out  of  reasonability  limit 
low  out  of  reasonability  limit 

high  out  of  reasonability  limit 
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0 Data  not  "being  updated  (due  to  telemetry  fail- 
ure) 

° Preferred  data  source 

0 Backup  source  of  data  being  used 

0 Point  is  in  tagged  condition 

In  some  instances  data  for  a given  parameter  may  be 
obtained  via  two  different  system  inputs  such  as, 
analog  tone  telemetry  data  and  digital  telemetry  data 
being  received  via  the  RTU.  In  such  cases  two  values 
for  a given  parameter  reside  in  the  data  base. 

Generally , all  using  programs  have  a preferred  data 
source  and  automatically  switch  to  the  backup  data 
source  in  the  event  that  the  data  quality  is  degraded. 
The  operator  should  have  the  capability  of  designating 
the  preferred  data  source  on  an  individual  point  basis. 

Integrated  MW  values  may  be  used  as  a backup  data  for 
the  hourly  accumulated  MWh  values.  When  backup  data 
is  being  used  it  should  be  so  quality  tagged.  Also, 
integrated  MW  values  may  be  automatically  compared 
to  accumulated  MWh  values  and  alarmed  if  the  differ- 
ence between  the  two  values  exceeds  an  operator- 
specified  limit. 

The  system  should  provide  the  capability  for  silent 
points.  Silent  points  are  those  devices  which  are 
not  being  monitored  by  an  RTU  or  points  at  a station 
that  does  not  contain  an  RTU.  The  state  of  these 
devices  are  changed  manually. 

All  data  shown  on  CRT  displays  should  indicate  the 
appropriate  level  of  data  quality.  This  includes 
real-time  calculated  data  values. 

In  the  event  of  detectable  communications  failures 
and  out  of  reasonability  range,  the  last  valid 
data  value  generally  remains  in  the  data  base.  Certain 
using  programs  trip  or  stop  operation  until  valid  data 
is  once  again  deposited  in  the  data  base. 

b . Real-Time  Data  Base 

Data  stored  in  the  real-time  data  base  is  that  pro- 
vided by  the  data  acquisition  system.  Operator- 
entered  data  may  override  missing  or  erroneous 
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telemetered  data.  All  manual  data  entries  are  to  be 
checked  for  reasonableness,  to  include  a check  against 
the  reasonableness  limits,  and  for  invalid  character 
entries.  The  capabilities  provided  include  calculated 
values  which  have  been  derived  from  telemetered  real- 
time data  base. 

The  real-time  data  base  maintains  all  quantities, 
status,  and  special  coding  information  resulting 
from  each  scan  cycle  or  from  operator  entries.  All 
data  should  be  table-driven  and  stored  in  a form 
directly  usable  by  user  programs  in  either  assembly 
language  or  FORTRAN.  All  frequently-scanned  data 
should  be  resident  in  the  main  memory. 

Data  and  status  processing  should  be  performed  for 
implemented  points  only  such  that  spare  future  data 
or  status  points  are  neither  processed  or  alarmed. 

c . System  Parameter  Data  Base 

Data  stored  in  the  system  parameter  data  base  include 
constants,  curves,  and  other  data  which  is  normally 
entered  manually  by  the  programmer  or  operator. 
Frequently  accessed  data  ds  main  memory  resident  and 
all  parameter  data  is  table-driven. 

Facilities  should  be  provided  for  entry  of  parameter 
data  either  by  a system  programmer  or  the  system 
operator.  The  choice  and  mechanism  will  depend  on  the 
particular  parameter  and  the  frequency  of  entry  or 
change.  Infrequently  entered  data  may  be  entered  by 
the  programmer  with  the  aid  of  the  data  base  compiler 
described  elsewhere  in  this  specification.  Operator 
entries  are  made  by  keyboard  in  conjunction  with 
interactive  CRT  displays  associated  with  specific 
power  system  applications.  All  operator  changes 
should  be  logged  on  the  operator  action  logger. 

d.  Results  Files 


Computed  results  from  programs  should  be  stored  in 
a file  which  can  be  accessed  by  other  programs, 
displays,  logs,  or  reports  which  require  these  re- 
sults as  inputs. 
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e . Report  History  Files 


The  history  file  is  a disk-based  file  which  stores  a 
given  set  of  hourly  information  for  subsequent  gener- 
ation of  hourly,  daily,  weekly,  and  monthly  reports. 

The  file  is  initially  sized  to  store,  on  an  hourly/ 
daily  basis,  200  quantities  for  a period  of  i+0  days. 
Provisions  should  be  made  for  CRT  display  of  any 
portion  of  this  file  and  subsequent  operator  correction 
or  substitution  of  data  items.  This  file  contains 
selected  hourly  history  data  for  more  full  days  and 
daily  summary  data  for  the  remaining  30  days.  All 
data  should  be  identifiable  and  selectable  for  display 
or  report  generation  on  the  basis  of  month,  day  of 
month,  hour  of  day  if  in  the  first  seven  days,  and 
individual  parameter.  Day  number  one  shall  be  consid- 
ered the  previous  2k- hour  period  where  all  hourly 
entries  have  been  completed. 

A storage  routine  should  be  provided  which  permits 
daily  transfer  <bf  hourly  data  from  the  history  file 
to  tape,  or  daily  transfer  to  a separate  disk  pack 
and  monthly  to  a magnetic  tape. 

Capability  should  be  provided  to  remount  history  file 
disks  or  tapes  for  subsequent  record  modifications 
and  reissuing  of  reports,  or  for  planning  and  engi- 
neering studies  without  disrupting  on-line  activities. 

The  following  information  is  stored  directly  or 
computed  and  stored  in  the  history  file  each  hour: 

0 MWh  values  from  each  generating  unit 

° MWh  values  from  each  tie 

° System  MW  load 

° EKP  MW  load 

° Net  generation 

° System  time  error 

° Inadvertent  interchange  (on-peak  and  off-peak) 

° Payback  correction  control  error-integrated 
° System  Lambda 
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Daily  one -hour  minimum  system  MWh  load 

° Daily  one-hour  maximum  system  MWh  load 

0 Net  scheduled  interchange  integrated  on  hourly 
basis  to  account  for  effects  of  ramping 

° On-line  reserve 

° Net  interchange  for  boundary  ties  (in  and  out) 

° Net  interchange  for  KU  loads  in  EK  area 

° Net  interchange  for  EK  loads  in  KU  area 

° Boundary  schedule  by  company  and  type 

0 Other  data  as  necessary  for  monthly  report 
generation 

f.  Alarm  File 

All  active  alarm  messages  for  the  power  system,  the 
microwave  system,  or  control  system  are  stored  in  an 
alarm  file.  Data  is  obtained  by  limit  checking  and 
alarm  generation  programs.  Each  alarm  message  is 
presented  as  English  language  information  on  either 
a CRT  display  or  the  alarm  logger.  Each  alarm  mes- 
sage should  carry  a critical/non-critical  attribute. 
Alarm  messages  may  be  deleted  from  this  file  by  the 
operator  or  in  some  cases  automatically  when  the 
alarm  condition  has  returned  to  normal. 

g.  Off-Normal  Status  File 


An  off-normal  status  file  may  also  be  provided  with 
storage  characteristics  similar  to  the  alarm  file. 

h.  Substation  Activity 


A substation  action  file  should  also  be  considered. 
This  message  file  would  contain  a time-tagged  record 
of  remote  station  status  change  activity.  All  circuit 
breaker  status  changes,  whether  caused  by  automatic 
action  or  supervised, would  be  stored.  In  addition, 
other  selected  status  changes  may  also  be  stored.  The 
file  may  be  created  by  sorting  on  device  descriptors 
from  all  incoming  alarms  and  from  supervisory  control 
actions . 
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Disturbance  File 


A system  disturbance  file  should  be  provided  which 
stores  pre-selected  real-time  values  in  a rotating 
file.  Under  normal  conditions  the  file  should  store 
the  previous  few  minutes  of  data.  When  a system  dis- 
turbance occurs  the  next  several  minutes  of  data 
will  be  stored.  The  occurance  of  a system  disturbance 
may  be  determined  by  either  of  two  methods:  (l)  an 
assigned  value  to  the  file  exceeds  a stored  limit 
(in  the  alarm  program);  or  (2)  the  operator  initiates 
by  depressing  a special  function  key. 

j . Real-Time  Data  Base  Dump 

Capability  should  be  provided  for  the  operator  to 
store  up  to  three  separate  snapshots  of  the  real-time 
data  base  on  a disk.  Providing  a tape  deck  is  avail- 
able, the  stored  snapshot  could  be  transferred  to 
tape  when  computer  resources  are  available.  Each 
real-time  data  base  snapshot  should  also  be  time-tagged. 
This  function  can  be  initiated  by  a special  function 
key  or  by  actuation  of  a CRT  poke  point. 

5-  Man-Machine  Software 


The  software  must  satisfy  the  system  functional  and 
operational  requirements.  The  requirements  are  concerned 
with  the  use  of  the  operator’s  consoles,  their  associated 
CRT  displays  and  entry  and  control  devices,  system  logging 
devices,  chart  recorders  and  panel-mounted  digital 
displays . 

a.  CRT  Displays 

Characteristics  of  each  CRT  display  should  be  described 
in  a format  description  table.  These  tables  provide 
the  data  to  be  processed  and  the  format  to  be  used; 
that  is,  display  field  position,  color  blink,  and 
status.  A real-time  formatting  routine  takes  this 
information  and  converts  it  into  suitable  formats 
for  driving  CRT  display  generator  equipment. 

The  man-machine  programming  provides  for  the  servicing 
of  all  operator  inputs  from  each  console.  Data  entry 
occurs  by  the  operator  entering  data  on  preformatted 
or  in  established  fields  on  CRT  displays.  Routines 
are  provided  for  checking  validity  of  input  data  and 
have  a one-for-one  response  with  the  operator.  . 
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Manually  entered  data  replaces  automatically  entered 
data  and  remains  until  the  operator  removes  this  con- 
straint. Manually  entered  data  for  AGC  shall  cause  an 
automatic  request. for  operator  review  once  each  hour. 
This  may  be  in  the  form  of  an  alarm. 

Programming  is  provided  to  service  individual  CRT 
functions.  The  following  functions  are  typical  and 
are  based  on  the  utilization  of  a CRT  picture  gener- 
ation program  which  is  described  in  a subsequent 
section: 

° Display  Control  Functions 

Service  requests  for  CRT  displays 

Call  and  schedule  routines  required  to 
complete  the  servicing  of  requests . 

Set  up  linkages  to  routines  and  files 
for  display  frame  retrieval,  dynamic 
update,  etc . 

Check  availability  of  all  facilities  de- 
fined in  routines  prior  to  attempting 
the  servicing  requests 

When  errors  occur,  identify  and  return 
diagnostic  error  information  to  the  user 

° Display  Selection 

Provide  a selection  mechanism  using  the 
keyboard  and/or  light  pen 

Provide  a page  forward /backward  capability 
including  wrap  around 

Provide  a display  destination  selection 
capability 

Provide  subsequent  level  display  detail 
call-up 

° Display  Retrieval 

Obtain  dynamic  and  static  information  from 
memory  and  combine  into  single  picture  file 
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Update  Functions 


Access  all  dynamic  elements  from  the  data 
base  for  picture  frames  currently  being 
displayed 

Periodically  update  all  dynamic  elements 
currently  being  displayed  per  the  latest 
status  and  measurement  values 

Update  only  those  dynamic  elements  that 
have  changed  since  the  last  periodic  update 

0 Applications 

Provide  routines  as  required  to  satisfy 
operational  requirements 

° Data  Entry 

Provide  a data  entry  facility 

° Input  Editing 

Provide  an  input  editing  function  and  error 
message  generation  in  accordance  with  the 
operational  requirements 

b . Console  Keyboards 

Two  forms  of  keyboard  control  are  generally  used  for 
the  console.  A general  purpose  keyboard  containing 
standard  alphanumeric  quantities,  CRT  graphic 
symbols,  and  CRT  edit  functions  interfaced  to  the  CRT 
display  generator,  and  a separate  set  of  special 
function  keys  should  be  considered.  These  special 
function  keys  may  be  used  for  station  menu  selection, 
application  program  menu  selection,  display  menu 
selection,  and  various  control  functions  such  as  TRIP, 
CLOSE,  RAISE,  LOWER,  ENTER,  CANCEL,  VALIDATE,  CLEAR, 
TAG,  TAG  REMOVE,  EXECUTE,  INHIBIT,  etc.  Some  of  these 
functions  may  also  be  duplicated  as  poke  points 
on  the  CRT  display.  Depression  of  these  keys  shall 
result  in  an  interrupt  to  the  on-line  computer 
requiring  near-immediate  service  of  the  request.  All 
requests  to  the  computer  shall  be  acknowledged  in  some 
form  indicating  to  the  operator  that  the  system  has 
received  and  is  processing  hie  request. 
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c.  Logging  and  Report  Generation  Programs- 


The  functional  capability  of  the  logging  printers 
should  be  operator  assignable  by  individual  function 
or  combined  function  if  its  units  are  available. 
Provisions  should  be  made  such  that  no  data  is  lost  if 
a printer  is  required  simultaneously  by  more  than  one 
using  program.  After  printout  of  a message,  the  line 
feed  shall  advance  to  permit  good  visibility  of  the 
last  line  without  the  necessity  of  manual  feed 
advance.  The  printer  motors  will  start  and  stop 
under  automatic  or  software  control  and  normally  run 
only  when  a message  is  to  be  printed. 

The  logging  and  report  generation  programs  provide  a 
high  level  language  capability  for  describing  headers 
and  report  formats,  and  for  accessing  data.  The  pro- 
gramming should  also  allow  for  describing  when  a re- 
port is  to  be  printed  and  on  what  device.  Typically, 
reports  are  initiated  on  the  basis  of: 

° An  operator  demand 

° A selected  event 

° A periodic  clock  such  as,  hourly,  daily,  week- 
ly, monthly,  etc. 

° A specified  time  and  date 

6 . Programmer’s  Aids 

a.  Standard  Assemblers  and  Compilers 

Provisions  should  be  made  for  a standard  assembler 
for  the  machines  provided.  The  most  recent  version 
of  a FORTRAN  IV  compiler  should  be  considered.  The 
compiler  must  be  capable  of  interfacing  with  system 
I/O  devices  through  software  modules.  Real-time  and 
on-line  operations  of  either  machine  should  be 
affected  by  use  of  standard  assemblers  and  compilers. 

b . Data  Base  and  CRT  Picture  Generation  and  Updating 

Only  a software  system  which  permits  a programmer 
or  engineer  to  generate  or  modify  the  data  base 
conveniently,  or  create  or  modify  CRT  pictures  and 
establish  the  necessary  linkages  to  the  system  data 
base  and  application  programs  without  disruption  of 
on-line  operations  should  be  considered.  The  data 
base  and  CRT  picture  generation  and  updating  system 
should  operate  in  an  English  language  conversional 
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mode  using  the  CRT  displays  and  associated  keyboards. 
The  system  instructions  should  lead  the  programmer  or 
engineer  through  all  necessary  steps  in  making  addi- 
tions or  modifications  to  the  data  base  and/or  CRT 
displays.  Changes  will  normally  be  made  on  a backup 
computer,  and  when  completed,  implemented  by  an  in- 
tentional failover  to  that  machine.  All  operator  or 
programmer  action  and  entries  associated  with  on-line 
compiling  should  be  recorded  in  the  form  of  an  audit 
trail  with  CRT  display  and  printout  capability. 

c . Utilities 

A software  system  should  be  considered  which  aids  the 
system  programmer  in  creating  new  report  formats  or 
modifying  existing  report  formats.  Standard  service 
and  utility  programs  for  on-line  and  off-line 
operations  should  be  provided  including  routines  for 
edit  and  debug,  dump,  maintenance,  diagnostic,  and 
loaders.  It  is  also  important  to  ascertain  what 
affect  the  use  of  diagnostics  have  on  normal  real-time 
and  on-line  operations. 

7 . Application  Software  Requirements 

All  power  application  programs  should  utilize  interactive 
CRT  displays.  All  data  entries  should  be  checked  for 
reasonableness,  and  error  messages  displayed  when  the 
checks  fail.  Except  for  time  of  day,  quiescent  system 
dynamic  information  on  all  CRT  displays  should  be  updated 
at  least  once  every  ten  seconds.  Alarm  information  should 
be  displayed  immediately. 

Displays  associated  with  the  application  programs  should 
be  directly  accessible  by  function  key,  through  an  inter- 
active CRT  display,  or  an  application  display  index. 

a.  System  Display  and  Monitoring 

CRT  displays  using  multi-color,  limited  graphics 
capability  generally  serve  as  the  primary  medium  for 
the  operator  to  observe  power  system  operation.  The 
information  is  conveyed  by  various  displays  generally 
categorized  by  the  following: 

° System  summary  display 
° Station  one-line  diagrams 
° Station  tabular  displays 
° Alarm  displays 
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Off-normal  status  displays 
0 Trend  displays 
° Configuration  displays 
° Utility  displays 
° Manually-entered  data  display 
° Tagged  device  display 
° Application  displays. 

Other  forms  of  monitoring  include  panel-mounted  chart 
recorders  and  panel-mounted  digital  readouts.  In 
addition  to  standard  handler  software  for  channel 
assignment,  drive,  scale  and  offset,  the  capability 
should  he  considered  for  operator  assignment,  via  a 
CRT  display,  of  trend  chart  recorder  channels  and 
digital  displays  to  any  variable  contained  in  the  data 
base . 

(1)  System  Summary  Display 

A system  summary  display  should  be  provided  which 
provides  an  overall  view  of  present  operating 
conditions . 

Information  on  this  display  shall  contain  as  a 
minimum : 

° Total  generation  capability  on-line 
° Total  generation 
° Total  system  load 
° On-line  reserve 
° Contol  error 
° System  frequency 
-actual 
-scheduled 
° Time  error 
0 AGC  mode 
° Net  interchange 
° Net  scheduled  interchange 
° Total  inadvertent  on-peak  and  off-peak 
° Net  interchange 

(2)  Station  One-Line  Diagrams 

One-line  diagrams  are  a virtual  must  in  today's 
modern  power  systems.  These  diagrams  shall  contain 
specific  real-time  data  and  status  information  and 
are  used  in  an  interactive  manner  by  the  operator 
for  supervisory  control. 
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Dynamic  information  that  may  be  included  on  a one- 
line  display  includes: 

° Circuit  breaker  open  or  closed 
0 Disconnect  switch  open  or  closed  (operator 
input ) 

° Device  tag  indication  (operator  input) 

° Line  flow  and  direction  (MW  and  MVAR) 

° Bus  volts  (kV) 

° Data  quality 

° Transformer  load  (MVA  - calculated) 

° RTU  "Local/Remote"  status 

(3)  Station  Tabular  Displays 

The  tabular  displays  contain  all  dynamic  .and 
static  information  contained  on  each  one-line 
diagram  plus  additional  information.  The  addition-^ 
al  information  may  consist  of  operational  limits, 
reasonability  limits,  and  normal  status.  These 
displays  also  may  be  used  to  inhibit  scan  of 
individual  points  and  have  indications  available 
indicating  a stop  scan  condition.  These  displays 
are  used  by  the  operator  in  an  interactive  mode 
to  substitute  quantities,  set  limits,  set  normal 
status,  and  for  scan  control.  An  area  for  station 
notes  should  be  made  a part  of  each  tabular 
display.  Narrative  notes  can  then  be  entered  by 
the  operator  using  the  keyboard  and  edit  features 
of  the  display  generators  and  entered  into  the 
computer  memory  for  subsequent  recall,  modifica- 
tion, cancellation,  or  additional  entry. 

( U)  Alarm  Displays 

A multi-page  alarm  display  should  be  provided 
which  displays  the  contents  of  the  alarm  file. 

When  the  alarm  display  is  requested,  the  page 
containing  the  most  recent  alarm  should  be 
displayed.  A single  graphic  character  associated 
with  each  incoming  alarm  line  should  flash  until 
the  alarm  is  acknowledged.  When  alarms  have  been 
cleared,  the  alarm  message  may  then  be  removed. 
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( 5 ) Off-normal  Status  Display 

An  off-normal  status  display  should  he  considered 
which  indicates  on  a point-by-point  basis,  dis- 
crepancies between  telemetered  status  points  and 
normal  status  bits  stored  in  the  data  base.  The 
off-normal  status  display  should  be  color  coded  to 
allow  identification  of  abnormal  states  caused  by 
an  alarm  action  or  supervisory  control  action.  The 
display  should  automatically  close  up  whenever 
messages  are  automatically  deleted  from  the  dis- 
play by  return  to  normal. 

(6)  Tagged  Device  Display 

A display  which  lists  all  tagged  devices  should  be 
provided.  This  display  can  be  created  by  scanning 
the  status  points  in  the  real-time  data  base  for 
a tagged  attribute.  It  is  not  necessary  to  main- 
tain a special  file  for  this  function.  Capability 
should  be  provided  for  printout  of  the  contents 
of  this  display. 

( 7 ) Video  Trend  Display 

In  addition  to  conventional  CRT  displays  for  one- 
lines,  tabular  data,  and  special  applications,  a 
video  trend  display  generator  may  also  be  provided 
This  capability  permits  up  to  four  simultaneous 
variables  to  be  plotted  continuously  against 
time  to  be  displayed  on  each  console. 

This  CRT  display  is  particularly  useful  if  it  is 
desirable  for  the  operator  to: 

° Select  the  desired  variables  from  the  real 
time  data  base  to  be  trended 
° Establish  a desired  time  baseline 
° Establish  scaling  factors  and  offset 
° Establish  shaded  areas 
° Annotate  video  trending  charts. 

b . Supervisory  Control  and  Tagging 

Supervisory  control  occur  via  operator  interaction 
with  a combination  of  interactive  CRT  display  and/or 
function  keys.  Two  types  of  displays  may  be  provided 
for  supervisory  control  interaction:  one-line  dia- 
grams and  station  tabular  displays.  The  control  and 
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interaction  philosophy  is  the  same  with  each  type 
display,  except  that  the  station  tabular  display 
includes  certain  features  not  available  on  the  one-line 
diagrams . 

Supervisory  control  involves  a "select-bef ore-operate" 
sequence.  The  preferred  steps  in  performing  a super- 
visory control  action  are  as  follows: 

0 Select  the  desired  station  one-line  diagram  or 
fetation  tabular  display 

0 Select  the  device  to  be  controlled  by  placing 
a cursor  or  light  pen  on  the  symbol  and 
actuating  a select  function.  Visual  verifica- 
tion of  this  step  should  be  provided.  If  the 
next  step  is  not  made  within  a prescribable 
period,  the  selection  is  automatically  cancel- 
led 

° Select  the  appropriate  TRIP/CLOSE  poke  point 
indicator  on  the  CRT  display  or  function  key. 
The  computer  then  addresses  the  appropriate 
RTU  where  the  message  is  decoded  and  the  in- 
dividual control  relay  is  selected.  The  RTU 
will  then  send  a checkback  message  to  the 
computer  containing  the  identification  of  the 
control  point.  The  computer,  after  verifying 
the  validity  of  the  checkback  message,  auto-  ', 
mat ic ally  issues  the  execute  command 

° Upon  successful  completion  of  the  operation,  a 
positive  acknowledgement  is  provided.  If  not, 
an  alarm  is  activated 

° A CANCEL  function  is  provided  to  allow  the 
operator  at  his  discretion  to  disengage  the 
operation  prior  to  executing  the  command. 

All  executed  supervisory  control  actions  are  printed 
as  they  occur  on  the  operator  action  logger  and  stored 
in  a history  file  for  later  use  in  a station  activity 
report.  Each  action  is  identified  with  the  time  of 
occurance  in  month,  day,  hour,  minute,  and  nearest  two 
seconds,  station  name,  device  name,  and  ID  number, 
originating  console  ID  and  action,  such  as  TRIP  or 
CLOSE . 

An  indication  is  provided  on  all  CRT  displays  associ-* 
ated  with  supervisory  control  to  show  RTU  LOCAL/ 

REMOTE  switch  position. 
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RAISE/LOWER  control  capability  for  future  transformers 
should  be  provided  and  implemented  in  a manner 
similar  to  TRIP/CLOSE.  For  each  RAISE  or  LOWER  command 
a single  timed  relay  closure  occurs  at  the  selected 
RTU.  Reselection  of  the  point  is  not  necessary  for 
successive  commands  which  occur  before  time  out.  A 
CANCEL  function  may  be  provided  to  disengage  the 
operation  at  the  operator's  discretion. 

Other  forms  of  required  control  action  requiring 
software  in  the  initial  system  include: 

° kWh  Freeze  Command  - Which,  on  the  hour  is 
transmitted  to  selected  RTU's  causing  kWh 
accumulating  registers  to  freeze 

0 Generation  Raise  Lower  Pulses  - Which  is 
derived  from  the  AGC  program  and  are  of 
multiple  duration 

0 Telemeter  Calibrate 


Checkback  is  not  required  with  these  control  modes. 

The  system  should  be  able  to  change  the  state  of 
silent  devices  through  a supervisory  control  action. 
The  system  should  also  provide  the  capability  to 
manually  change  the  state  of  a point  that  is  out-of- 
scan. 

A simple  form  of  device  tagging  should  be  provided. 
This  function  is  closely  related  to  supervisory 
control  and  utilizes  the  station  one-line  diagrams 
and  the  station  tabular  displays  in  an  operator 
interactive  manner. 

Clearance  requests  and  other  specific  information 
related  to  the  type  or  purpose  of  the  tagged  condition 
is  stored  by  the  computer.  Tagging  shall  be 
accomplished  by  positioning  the  cursor  on  the  station 
tabular  display  over  the  desired  device,  entering 
a reference  number  and  depressing  TAG.  Removing  a tag 
is  accomplished  by  positioning  the  cursor  on  the 
station  tabular  display  over  the  desired  device  and 
actuating  REMOVE  TAG,  Any  supervised  device  which 
has  been  tagged  is  inhibited  from  any  supervisory 
control  action.  Each  tag  or  tag  removal  action  is 
printed  on  the  operator  action  logger,  showing  date, 
time  of  day,  action  taken,  station,  point  ID,  and 
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reference  number.  Capability  should  be  provided  to 
tag  devices  which  are  not  supervised  or  which  may  be 
at  a station  with  no  RTU.  Any  power  system  device 
which  has  been  tagged  must  appear  in  a tagged  state 
on  any  display  showing  that  device. 

c . Limit  Checking,  Status  Checking,  and  Alarming 

(1)  Limit  Checking 

Specified  measurements  or  other  variables  should 
be  tested  against  stored  limits  periodically  or 
under  program  control.  Limit  files  are  stored 
where  limit  data  is  used  in  routine  or  special 
application  tests.  The  contents  of  all  limit  files 
should  be  available  for  display  on  the  station 
tabular  CRT  displays  with  the  capability  for 
change  by  the  operator.  An  alarm  is  generated  and 
logged  whenever  and  operating  limit  is  exceeded. 

Reasonableness  limit  checks  are  applied  to  all 
manually  entered  data  or  to  data  where  operating 
limits  have  been  exceeded.  These  include  high, 
low,  sign  and  non-numeric  checks.  They  define  the 
possible  outside  limits  for  each  measurement 
based  upon  physical  restrictions.  If  a reason- 
ableness check  fails  following  manual  data  entry, 
an  error  message  is  generated  and  displayed 
indicating  the  general  nature  of  the  failure. 
Reasonability  limit  magnitude  and  sign  values 
are  independent  of  operating  limit  magnitudes 
and  sign  values. 

(2)  Status  Checking 

The  status  of  all  devices  or  conditions  which  can 
be  one  of  two  states  is  checked  against  stored 
normal  status.  Two  states,  typically  OPEN  or 
CLOSED,  are  stored  and  compared  with  status 
points  for  detection  of  off -normal  states.  The 
normal  state  of  each  device  is  stored  in  a file 
and  made  available  on  the  station  tabular  CRT 
displays . 

(3)  System  Alarming 

It  is  necessary  to  monitor  selected  analog  and 
status  points  for  alarm  conditions.  Certain 
application  programs  may  also  produce  alarms.  An 
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alarm  should  be  generated,  stored  in  the  alarm 
file,  and  printed  if  any  of  the  following 
conditions  occur: 

0 An  unauthorized  change  of  status  is  detected 
° An  operational  or  reasonability  (high  or 
low)  limit  is  exceeded 
0 Error  thresholds  are  exceeded 
° A supervisory  controlled  device  fails  to 
operate 

0 An  RTU  fails  to  respond  correctly 
0 Failure  of  selected  ECS  hardware 
° When  requested  by  an  application  program 

Two  alarm  classifications  are  generally  provided; 
critical  and  non-critical.  Classification  of 
alarms  are  assignable  as  part  of  the  data  base 
compilation  procedure.  Critical  alarms  are  those 
requiring  immediate  operator  attention  and 
acknowledgement.  Non-critical  alarms  are  brought 
to  the  attention  of  the  operator  but  immediate 
operator  reaction  or  acknowledgement  is  not 
required. 

An  alarm  file  should  be  provided  for  the  storage 
of  up  to  150  alarm  messages.  The  alarm  program 
assembles  each  alarm  message  from  a combination 
of  telemetered  information  and  stored  message 
elements.  Each  alarm  message  contains  the 
following  information  as  a minimum: 

0 Date 

° Time  of  day  - hours,  minutes,  seconds 
° Station  ID  where  alarm  occured  (four-letter 
minimum) 

° Device  or  measurement  name  and  ID  (four- 
digit minimum) 

° Nature  of  alarm  such  as  TRIP,  CLOSE,  HIGH, 

° LOW,  RTU,  FAILURE,  etc.  along  with  an 
English  language  narrative  description 
° Sequence  of  events,  where  available,  such  as 
close /trip/close 

0 Stored  analog  limit  and  actual  value  which 
produced  alarm 

Information  contained  in  alarm  messages  need  not 
be  updated  by  subsequent  scans  after  the  message 
is  stored.  Status  and  event  (TRIP/CLOSE)  alarms 
may  be  stored  in  the  substation  activity  file  for 


111-62 


report  generation.  Whenever  an  alarm  occurs,  the 
following  should  occur: 

0 An  Alarm  mes.sage  is  composed 

° The  alarm  message  is  stored  in  the  alarm 
file  and  he  presented  on  the  alarm  display 

0 Audible  alarms  occur  as  follows: 

(a)  A repeating  two-tone  alarm  for 
critical  alarms 

(b)  A non-repeating  tone  for  non-critical 
alarms 

0 The  alarm  message  is  printed  on  the  alarm 
logger 

° The  device  symbol  on  one-line  diagrams  and 
the  analog  or  status  point  on  a station 
tabular  display  shall  blink 

When  a critical  alarm  occurs,  it  is  acknowledged 
by  the  operator.  A symbol  by  each  unacknowledged 
alarm  blinks  on  all  CRT  displays.  Acknowledgement 
shall  cause  unacknowledged  alarms  to  cease 
blinking,  return-to-normal  alarms  to  clear  from 
the  file,  and  silence  the  audible  alarm.  Non- 
critical  alarms  should  be  automatically  acknowl- 
edged by  the  system  after  two  seconds  if  operator 
acknowledgement  has  not  occured. 

Additional  required  features  of  the  alarm  program 
include : 

0 Flashing  red  represents  unacknowledged  new 
alarm,  solid  red  represents  acknowledged 
alarm  and  flashing  white  represents  and  un- 
acknowledged alarm  returned  to  normal  state 

0 Audible  devices  may  be  silenced  either  by  an 
"Alarm  Silence"  or  "Alarm  Acknowledge" 
function  key.  Alarm  Silence  should  not 
acknowledge  an  alarm  but  shall  only  inhibit 
the  audio  device.  A subsequent  new  alarm 
should  cause  the  alarm  chime  to  sound.  An 
alarm  chime  "inhibit"  function  should  be 
provided  which  allows  the  operator  to 
silence  the  chimes  completely 

0 Capability  to  acknowledge  alarms  individual- 
ly or  to  acknowledge  all  new  alarms 
simultaneously  from  the  alarm  page.  Oper- 
ator acknowledgement  of  an  alarm(s)  logged 
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out  on  the  operator  action  logger 

0 Alarm  messages  may  be  arranged  in  chron- 
ological or  reverse  order  on  the  CRT; 
however,  the  page  with  the  latest  alarm 
is  always  displayed  when  the  alarm  list  is 
requested 

° An  alarm  message  should  remain  on  the  alarm 
summary  until  the  operator  has  subsequently 
acknowledged  the  return-to-normal  alarm 
condition  or  subsequently  chooses  to  delete 
the  alarm 

° When  an  alarm  point  returns  to  its  normal 
state  another  alarm  message  (in  white)  is 
generated.  When  the  operator  acknowledges 
the  return  to  normal  condition  all  messages 
pertaining  to  the  particular  alarm  are 
removed  from  the  system 

° Blocking  of  alarms  should  occur  when:  (a)  a 
status  or  analog  point  is  taken  off  scan, 

(b)  when  limits  have  been  removed,  or  (c) 
the  alarming  of  a point  has  been  blocked 

° If  the  alarm  file  becomes  full,  new  incoming 
alarms  should  continue  to  be  printed  of  the 
alarm  logger 

0 Prior  to  the  file  becoming  full  the  operator 
should  receive  an  alarm  of  the  pending 
condition.  He  should  also  receive  an  alarm 
when  the  file  is  full 

0 The  alarm  logger  should  print  each  alarm 
message  as  it  is  available  and  alarm  return- 
to-normal  conditions  when  they  occur.  The 
operator  action  logger  records  all  operator 
action  pertaining  to  alarm  actions  performed 
by  the  operator 

( h)  Required  Program  Inputs 

Information  inputs  to  the  alarm  program  shall  be: 

0 Time  and  date 

0 Status  points 

0 Analog  points 
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Supervisory  control  program 
0 Normal  state  conditions 
0 Alarm  classification 
° Operator  action 
° Alarm  blocking  conditions 
° Function  keys 

( 5 ) Program  Outputs 

0 Alarm  messages  on  the  alarm  logger  (English 
language ) 

° Alarm  messages  to  substain  activity  file  for 
status  and  TRIP /CLOSE  events 
° Alarm  messages  on  the  appropriate  CRT  dis- 
plays (English  language) 

0 Operator  action  logging  of  alarm  acknowl- 
edgement and  deletions 
° Audible  alarms 

(6)  Displays  and  Operator  Interaction 

The  following  interfaces  are  provided  for  alarm 
control  and  status  by  the  operator: 

0 Interactive  CRT  displays 

Any  CRT  picture  where  alarmed  point  is 
displayed 

Alarm  summary  display 

Dedicated  critical  alarm  messages  on 

every  display 

0 Printing  Devices 
Alarm  logger 
Operator  action  logger 

° Audible  Devices 

Repeating  stroke  two-tone  chime  for 
critical  alarms 

Single  stroke  chime  for  non-critical 
alarm  and  return-to-normal 

° Function  Keys 

Acknowledge. 

Inhibit  (chime) 

Silence  (chime) 

Delete 
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(6)  Program  Execution 


An  alarm  program  operates  in  a variety  of  modes. 
Execution  of  each  mode  normally  occurs  from  one  of 
the  following  sources: 

° Automatic  detection  of  an  alarm  condition 
° Automatic  return  of  out-of-limits  conditions 
° Operator  inputs-requests 

d.  Teletype  Communication 

Programming  should  be  provided  for  a teletype  network 
communications  program  which  shall  permit  the  operator 
to  compose  a preformatted  message,  and  when  correct, 
transmit  the  message  via  an  existing  teletype  network 
by  operator  demand  or  when  polled. 

In  addition  to  the  preformatted  forms  a free-form 
message  capability  should  also  be  provided.  The  free- 
form display  should  include  provisions  for  addressing 
the  message  to  individual  stations,  groups  of  stations 
or  broadcasting  the  message  to  all  stations.  Logic 
and  buffering  should  be  provided  to  handle  messages  to 
stations  which  are  busy  and  require  delayed  transmis- 
sion . 

Data  input  requirements  for  the  teletype  program  are: 

° Real-time  System  Inputs 

System  time  and  date 

0 Manually-Entered  Data 

Values  and  narrative  text 
Text  editing 

Operator  selection  of  addresses 
Transmit  command 

Teletype  network  message  input  displays  should  allow 
the  operator  to  input  preformatted  message  data  to  the 
system. 

The  operator  should  be  provided  with  the  following 
interfaces : 

° Interactive  CRT  Displays 

Preformatted  message  pages  (2  minimum) 
Narrative  message  pages  (2  minimum) 
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Printing  Devices 

Operator  action  logger 
Line  printer  (alternate  destination) 

e . Log  and  Report  Generation 

Alarms  and  operator  actions  are  printed  by  the  char- 
acter printers;  One  printer  shall  normally  print  alarm 
messages  and  the  other  operator  action  information. 
Another  printer  may  he  used  with  the  programmer's 
console  and  may  serve  as  a backup  for  the  other 
logging  printers.  The  printer  motors  start  and  stop 
under  software  control  and  will  normally  run  only 
when  a message  is  to  be  printed. 

Complete  programming  should  be  provided  by  the  vendor 
for  the  logs  and  reports  listed  below.  All  logs  and 
reports  should  include  the  date  and  time  of  printout 
and  the  date  of  the  data  contained  within  the  report. 

(1)  Logs 

Capability  should  be  provided  to  automatically 
generate  the  following  logs: 

0 Alarm  Log  - Printed  as  alarms  occur.  Data  be 
arranged  and  formatted  by  the  alarm  program 
and  stored  in  the  alarm  file 

° Operation  Action  Log  - Printed  following 
each  operator  control  or  data  modification 
action.  Examples  include  all  supervisory 
control  action,  data  substitution,  alarm 
delete,  and  operator  notes.  All  data  for 
this  log  is  formatted  and  arranged  by  the 
originating  program.  All  outputs  to  this 
logger  are  time  tagged 

(2)  Reports 

Capability  should  be  provided  to  generate  reports 
automatically  following  each  2U-hour  period  or  by 
operator  request.  The  reports  to  be  generated  are: 

0 Hourly  Net  Generation  Summary  - This  report 
shows  hourly  net  MWH  for  all  major  units 
and  station  totals  for  smaller  stations 
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Scheduled  Interchange  Summary  - This  report 
shows  the  hourly  scheduled  in  and  out  energy 
and  type  of  interchange  over  a 2U-hour  per- 
iod with  each  interfacing  company.  The  type 
of  interchange  is  also  identified 

System  Load  Summary  - This  report  provides 
a summary  of  system  load  on  an  hourly  basis 
including  generation,  metered  intertie, 
scheduled  intertie,  inadvertant,  on-line 
reserve,  off-line  reserve  and  capacity  down 
for  maintenance 

Actual  Interchange  Summary  - This  report 
shows  actual  interchange  on  an  hourly  basis 
between  utilities 

Tie  Line  Summary  - This  report  will  provide 
a record  of  actual  hourly  flow,  in  and  out, 
over  all  metered  intertie  points 

Operator  Message  Log  Summary  - This  report 
will  show  the  contents  of  all  operator 
stored  messages 

° Communication  Channel  Error  Summary  - This 
report  is  derived  from  the  alarm  file  and 
shall  summarize  all  channel  failure  condi- 
tions or  excessive  channel  dropouts.  In 
addition,  this  report  summarizes  all  analog 
channel  failures  (backup  values  via  local 
RTU)  and  communi cat ions  alarms 
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D.  Man/Machine  Interface  Requirements 


This  section  examines  the  man/machine  interface  features  to  be 
considered  for  incorporation  into  the  control  system  design. 
Man/machine  subsystems  provide  the  means  for  System  Dispatchers 
to  communicate  with  the  computer  system  and  to  access  power 
system  data.  The  System  Dispatcher  positioned  at  his  console 
during  normal,  emergency,  or  restorative  system  conditions,  must 
reach  decisions  critical  to  the  power  system.  The  validity  of 
the  results  is  directly  related  to  the  conciseness  and  logical 
form  of  the  information.  In  many  instances,  rapid  ac.cess  to  a 
complete  picture  of  the  prevailing  conditions  in  the  power 
system  is  critical.  Electric  system  Borrower  Dispatch  personnel 
need  modern  man/machine  interfaces  to  support  these  operational 
requirements.  This  section  presents  a discussion  of  man/machine 
facilities  which  are  convenient  and  cost-effective. 

The  man/machine  equipment  must  satisfy  immediate  needs  and  fu- 
ture expansion  requirements.  A compromise  acceptable  at  instal- 
lation time  which  does  not  adequately  satisfy  future  needs,  only 
defers  operational  hazards  and  substantially  increases  the 
long-term  costs  of  the  project.  Generators,  substations  and 
sub-transmission  lines  that  strengthen  the  power  system  are  be- 
ing added  regularly.  Anticipation  of  this  normal  growth  in  the 
system, as  it  relates  to  man/machine  interface  design,  will  en- 
sure continuity  of  reliable  power  system  operation.  The  de- 
scription of  the  System  Dispatcher  console,  which  is  the  focal 
point  of  man/machine  interface,  considers  these  requirements. 

1 . CRT-based  Interface 

Modern  control  systems  utilize  the  CRT  as  the  principle 
man/machine  interface.  The  CRT's  versitility  provides  sol- 
utions to  the  many  requirements  of  a System  Dispatcher. 
Utilizing  both  alphanumeric  tabulation  formats  and  schemat- 
ic or  "limited  graphic"  formats,  the  CRT  subsystem  can 
reinforce  data  presentations,  dynamically  focus  the  Dis- 
patchers with  a compact  and  powerful  operational  interface, 
while  maintaining  a large  capacity  for  expansion.  Additions 
to  the  power  network  system  control  functions  can  usually 
be  performed  without  physically  altering  the  CRT  man/' 
machine  interface. 

The  data  sorting  and  organizing  capability  of  the  computer 
allows  logical  formating  of  system  data  required  by  the 
Dispatcher.  CRT  display  units  are  available  with  seven- 
color  displays,  including  alphanumeric  and  schematic  formats. 
State-of-the-art  CRT  display  units  and  driver  software  per- 
mit status  and  control  points  to  be  organized  on  single- 
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line  substation  CRT  displays  with  dynamically-updated 
telemetered  values  such  as,  MW,  MVAR  and  KV.  Functional 
groupings  of  many  of  these  same  data  quantities  on  other 
displays  more  readily  facilitates  monitoring  and  control. 
This  flexibility  accommodates  a virtually  limitless  reper- 
toire of  functional  data  presentations  viewable  through  a 
common  display  subsystem,  and  fosters  the  use  of  the  CRT  as 
a focal  point  for  display  of  power  system  information.  CRT 
features  such  as  character  blinking,  color  change,  color 
inversion,  underlining  and  special  symbol  annotation  also 
direct  Dispatcher  attention  to  particular  categories  and 
changes  of  system  data. 

a.  Expansion  Capabilities  of  CRTs 

To  add  new  displays,  new  analytical  programs,  new 
equipment, or  substations  to  a CRT-based  SCADA  system, 
requires  only  internal  changes  and  additions.  The 
external  physical  appearance  of  the  system  should 
remain  unchanged  throughout  its  life.  Thus,  no  new 
steelwork,  floor  space  or  functional  change  is  re- 
quired to  respond  to  normal  system  growth.  It  should 
be  noted  however,  that  the  ability  of  the  CRT-based 
system  to  grow  is  dependent  on  carefully  designed 
growth  capabilities.  The  future  must  be  sufficiently 
described  on  carefully  designed  growth  capabilities. 

The  future  must  be  sufficiently  described  in  the 
specification  to  allow  the  Vendor  to  size  main  memory, 
auxiliary  memory,  computational  and  channel  capability 
to  absorb  all  known  future  needs  with  a healthy  safety 
factor.  The  software  structure  should  be  sufficiently 
modular  and  parameterized  to  permit  future  growth  with 
a minimum  of  disruption.  The  state-of-the-art  in  CRT 
updating  (i.e.,  the  building,  integration  and  activa- 
tion of  new  alphanumeric  and  one-line  displays)  has 
responded  to  the  need  of  the  users  to  make  necessary 
changes  and  additions  on-line,  with  no  interference  to 
critical  functions. 

The  CRT-based  system  will  require  a small  functional 
pushbutton  panel  and  keyboard.  Pushbuttons  will  perform 
control  actions,  initiate  functions,  and  call  for  index 
displays.  The  keyboard,  similar  in  design  and  function 
to  a standard  typist’s  keyboard,  will  be  used  for  Dis- 
patcher entry  of  numeric  values  and  repetitive  alpha- 
numeric messages.  The  ability  to  build  a new  display 
and  include  it  on  a general  index  display  for  its  cat- 
egory allows  the  Programmer /Engineer  to  expand  any  ex- 
isting function  to  the  limit  of  main  and  auxiliary 
storage  available.  Spare  pushbuttons  allow  the  Program- 
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mer /Engineer  to  include  completely  new  functions. 

b . Responsiveness  of  CRT-based  Systems 

As  opposed  to  the  dispersed  nature  of  traditional  hard- 
wired masters,  the  CRT  represents  a highly  concentrated 
form  of  man/machine  interface.  Physical  movement  of 
the  Dispatcher  is  minimized,  the  data  he  requires  is 
in  front  of  him,  either  automatically,  or  on  demand.  The 
greater  the  variety  of  the  information  he  requires  the 
greater  the  efficiency  of  the  CRT  approach  becomes. 
Control  actions  can  be  performed  on  the  CRT  with  the 
insertion  of  new  parameters  on  the  same  display  on 
which  related  data  is  displayed.  Related  data  includes 
overviews,  one-line  diagrams,  and  study  outputs.  The 
ability  of  the  CRT  to  provide  all  of  this  data  swiftly 
must  increase  the  overall  security  of  the  electrical 
system . 

2.  Representative  Alphanumeric  CRT  Displays 

One  of  the  advantages  of  a truly  flexible  CRT  system  is 
that  it  is  in  no  way  bound  by  the  manufacturer's  standard 
displays.  Dispatchers  can  incorporate  any  display  based  on 
data  existing  in  the  system  data  base.  If  the  data  does 
not  exist  in  the  data  base  an  appropriate  analytical  pro- 
gram must  be  written  to  provide  it. 

The  CRT  subsystem  will  be  the  heart  of  the  mani/machine 
interface.  The  CRT  displays  will  allow  the  dispatchers  to 
view  any  pertinent  information, and  to  make  required  en- 
tries, as  well  as  allow  the  programmer  to  maintain  the 
s of tware  system . 

A parameter  of  vital  importance  to  the  performance  of  the 
system  is  the  time  required  to  respond  to  an  operator  re- 
quest for  a display.  The  average  response  time  to  display 
requests  should  be  no  less  than  one  second, and  no  more 
than  two  seconds  with  heavy  system  activity  occuring.  This 
response  time  is  the  critical  measure  of  how  much  the 
control  system  will  be  of  aid  during  system  disturbance. 

All  displays,  alphanumeric  and  graphic,  will  include  seme 
common  attributes.  Fixed  fields  will  contain  time  and  date 
information,  the  display  title,  and,  for  multiple  page 
displays,  a page  number.  Each  display  should  include  a 
'scratch  pad'  area,  allowing  special  purpose  messages  or 
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tag  information  to  be  added  on-line.  As  an  adjunct  to  the 
scratch  pad,  dedicated  alarm  lines  common  to  all  displays 
should  be  provided  to  display  a small  number  (two  to  five) 
of  the  latest  alarms.  When  an  alarm  occurs,  the  Dispatcher 
can  determine  the  alarm's  location,  normally  via  a short 
acronym,  and,  by  cursor  selection,  call  up  the  one-line  of 
the  alarming  RTU.  The  following  briefly  summarize  seme 
typical  display  types: 

° Index  Displays . A tabular  listing  used  by  the 
System  Dispatcher  in  lieu  of  pushbuttons  to  select 
substation  displays.  The  Substation  Index  Displays 
obviate  the  need  for  display  selection  hardware,  and 
simplifies  additions  as  new  substations  are  added  to 
the  power  system.  Additional  Index  Displays  will  be 
provided  for  other  categories  of  displays,  such  as 
generating  stations  and  system  logs 

° Substation  Display  A switchyard  may  be  used  as  an 
example  of  an  alphanumeric  display  to  present  data, 
and  to  input  monitoring  parameters.  The  Dispatcher 
may  enter  high  and  low  limits,  status  and  other 
parameters,  and  note  the  actual  MW  and  status  of 
equipment 

0 Generation  and  Load  Summary  A tabular  listing  of 
summary  data  relating  to  generation  and  load  as  well 
as  individual  Generation  Units.  It  should  include 
telemetered  data  and  calculated  values  such  as  cap- 
acity and  available  reserve 

° Event  Display.  The  Events  Display  allows  the  Dis- 
patcher to  view  a copy  of  the  ''N"  most  recent 
messages.  The  display  is  ‘'rolled''  - i.e.,  new  events 
are  added  at  the  top  of  the  page  as  they  occur,  the 
existing  data  are  bumped  downward,  and  the  bottom 
most  ( :Nth  ) entry  is  deleted.  All  system  events, 
including  alarms,  Dispatcher  control  actions,  and 
control  system  status  messages,  are  included  on  this 
display 

0 Off  Normal  Display  All  active  system  abnormalities 
and  alarms  are  included  on  this  display.  Data  dis- 
played includes  the  time  of  the  event,  a priority  or 
type  message,  the  name  of  the  RTU  location,  device 
location,  device  number,  and  a description  of  the 
abnormality.  Key  to  the  understanding  of  the  display 
is  the  definition  of  ‘'ALARM"  and  "AUTH  CHANGE".  An 
alarm  is  an  uncommanded  change  of  state  or  a limit 
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viola/tion.  Alarms  will  be  displayed  until  they  have 
been  acknowledged  and  have  returned  to  normal.  An 
Authorized  Change  (AUTH  CHANGE)  is  a change  of  state 
caused  by  Dispatcher  action.  Authorized  Changes  will 
be  displayed  as  long  as  the  resulting  status  differs 
from  a predefined  'Normal'  state.  The  Off  Normal 
Display  serves  as  an  alarm  summary,  and  a descrip- 
tion of  system  operation  differing  from  the  norm 

o Load  Shedding . This  display  provides  a listing  of 
loads  to  be  interrupted  during  an  emergency.  The 
list  should  be  updated  periodically.  The  System 
Dispatcher  may  initiate  control  from  this  display. 
Optional  supporting  programs  can  be  provided  to 
track  outage  time  and  alert  the  System  Dispatcher  to 
transfer  outage  to  the  next  scheduled  group 

o Interchange  Schedule  A listing  of  all  scheduled 
interchanges,  active  and  pending,  is  maintained  on 
this  display.  The  Dispatcher  can  enter  negotiated 
transactions  in  advance  of  their  scheduled  initia- 
tion, and  utilize  the  computer  to  activate,  end,  and 
log  the  interchange 

o Tagging  List  This  display  will  list  all  the  devices 
currently  in  a tagged  condition,  along  with  pertinent 
information  about  the  tag  including  time,  date,  and 
reason  for  the  tag.  When  a device  is  tagged  (via  the 
station  display)  the  pertinent  information  will 
automatically  be  entered  on  the  tagging  list  display, 
and  two  lines  will  be  available  for  free-form  mess- 
ages to  be  entered  by  the  dispatcher.  Tags  may  only 
be  removed  via  the  tagging  list  display.  Multiple 
levels  of  tagging  will  be  supported  by  the  system, 
and  the  software  will  be  designed  to  provide  as  much 
security  as  possible, to  prevent  inadvertent  removal 
of  tags 

° Alarm  Lists  The  alarm  lists  are  the  means  of  pre- 
senting alarms  to  the  dispatchers.  Acknowledged 
alarms  would  be  distinguished  from  unacknowledged 
alarms.  An  abnormal  summary  would  list  all  devices 
that  are  in  abnormal  conditions.  This  would  include 
analog  values  that  exceed  their  limits.  The  occurence 
of  one  or  more  alarms  will  not  restrict  the  dis- 
patchers from  viewing  any  displays 
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Generation  Dispatch  Displays:  These  allow  the 

dispatchers  to  monitor  and  enter  pertinent  informa- 
tion about  the  generation  dispatch  function.  Inter- 
change schedules,  as  well  as  generator  control 
inf or mat ion, such  as  unit  operating  mode,  are  dealt 
with  in  these  formats.  The  AGC  capability  functions 
will  be  procured,but  not  used  initially.  The  feature 
will  be  available  to  be''passively"  used  by  the  dis- 
patcher 

° Master  Station  Status  and  Control  Displays:  These 

displays  would  show  the  configuration  and  status  of 
the  hardware  system.  This  includes  the  configuration 
and  assignment  of  the  computer  systems  and  peripher- 
als 

° Scratchpad  and  Message  Displays:  These  formats  al- 

low the  dispatchers  to  make  free-form  entries  on  the 
CRTs.  These  might  be  messages  to  the  next  shift,  or 
trying  out  new  display  formats  to  be  implemented 
by  a programmer.  There  will  be  a field  on  the  station 
displays  to  indicate  whether  there  are  any  messages 
relevant  to  that  substation 

0 Static  Displays:  These  displays  contain  no  variable 

data  on  them,  and  are  for  informational  purposes  only. 
Switching  information  or  other  procedures  might  be 
summarized  on  the  static  displays 

° Miscellaneous  Functions:  Various  other  functions 

such  as  trend  recorder  pen  assignment,  or  RTU 
communications  and  scan  control,  would  be  carried  out 
by  displays  accessible  to  the  dispatchers 

° Log  Formats : The  data  for  the  periodic  logs  may  be 

reviewed  and  altered  via  the  Log  Format  Displays. 
These  logs  include  those  that  are  output  each  hour, 
as  well  as  those  that  appear  once  a day 

° Programmer ' s Formats : The  Programmer's  formats 

allow  those  functions  that  are  performed  by  a pro- 
grammer, or  other  trained  person, to  be  accomplished 
from  a console,  using  the  CRT  display  system.  These 
functions  include: 

Data  Base  Editing 

CRT  Display  Format  Editing 

Utility  Functions 

AGC  Performance  Tuning  (when  AGC  is  used) 
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3 . Representative  Limited  Graphic  Displays 


Some  data  favors  a tabulated  alphanumeric  display  such  as 
those  listed  in  Section  2.  Limited  graphic  capability  adds 
another  dimension  to  CRT  monitoring  and  control.  The  im- 
mediate availability  of  the  visual  image  of  a one-line 
diagram  eliminates  the  necessity  for  most  loose-leaf  books, 
drawings  or  other  extra- computer  references.  The  tools  of 
the  Dispatcher's  trade  are  directly  in  front  of  him, 
available  at  the  push  of  a button  and  the  movement  of  a 
cursor.  Dynamic  schematics  of  substations  are  particularly 
useful  when  a direct  control  action  is  required.  All 
stages  of  input,  verification,  equipment  change,  and  data 
values  are  dynamically  displayed.  Although  limited  graphic 
CRTs  with  color  capability  do  represent  added  system 
expense  for  both  hardware  and  software,  the  added  cost  is 
small  considering  the  technical  advantages. 

A heirarchial  set  of  graphic  displays,  linked  to  correspond- 
ing alphanumeric  displays,  is  recommended.  The  Dispatchers 
should  be  provided  with  displays  which  provide  a quick 
overview  of  system  status,  and  which  serve  as  indices  into 
more  detailed  displays  showing  all  system  data.  The  follow- 
ing is  a representative  display  strategy: 

Bulk  Power  Diagram:  This  display  has  the  attributes 
normally  associated  with  a dynamic  mapboard, and  also 
serves  as  an  index  to  substation  displays.  It  can  be 
segmented  into  several  displays  to  fit  a CRT.  Each 
display  will  cover  a geographic  or  operating  area. 
Interconnections  among  the  segments  will  be  shown, 
and  segments  can  be  called  one  from  the  other 
through  cursor  selection.  Initial  selection  of  the 
desired  segment  of  this  diagram  can  be  accomplished 
through  use  of  dedicated  pushbuttons,  back-lighted, 
and/or  flashing  to  indicate  the  presence  of  an  alarm, 
or  through  an  index  block  diagram  and  cursor-sen- 
sitive points.  The  Bulk  Power  Diagram  would  have  the 
following  attributes: 

0 Substations  will  be  represented  by  squares 

annotated  with  the  substation  name  or  a special 
symbol 

0 Flashing  of  the  symbol  representing  the  facility 
will  show  substation  alarms  and  circuit  tripping 

° Selection  of  a substation  block  will  result  in 
the  display  of  the  substation  diagram  of  that 
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particular  station 


Substation  Displays:  These  displays  will  have  the 

following  characteristics: 

O 

Status  of  all  monitored  devices  will  be  dynamic- 
ally updated 

° Status  of  any  non-monitored  devices  will  be 
entered  by  the  System  Dispatcher 

° Analog  values  will  be  dynamically  updated  when 
shown 

O 

All  controllable  devices, including  tap  changing 
transformers  may  be  controlled  from  this  display 

Alarms  associated  with  this  display  may  be 
acknowledged  from  this  display 

U . Console  Configuration 

Efficient  interaction  between  man  and  machine,  and  expand- 
ability that  parallels  power  system  growth,  is  the  major 
objective  of  the  console  design.  Communicating  with  out- 
lying districts  and  other  utilities,  preparing  reports, 
executing  switching  orders,  monitoring  power  system 
performance,  and  executing  control  actions,  should  be  con- 
sidered in  the  overall  design.  Access  to  frequently  used 
devices  should  be  convenient.  Consoles  should  be  compact 
and  expandable.  Sight  paths  to  non-console  mounted  devices 
such  as  wall  mounted  recorders  and  indicators  should  not 
be  obstructed  by  the  consoles. 

Control  center  designs  typically  provide  a minimum  of  two 
or  three  operating  positions: 

° Dispatcher  - used  for  normal  operations 

° Second  Dispatcher  - used  only  during  stress  condi- 
tions 

0 Programmer/Engineer/Training  (P/E/T)  - used  for 
off-line  and  background  functions,  available  for 
engineering  ude  during  stress  situations 

The  two  Dispatcher  stations  should  be  located  on  the  oper- 
ating room  floor,  while  the  programmer  position  may  be 
located  in  the  computer  equipment  room. 
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The  minimum  acceptable  configuration  for  the  consoles 
would  be  two,  two  CRT  consoles,  one  utilized  as  a Dispatch- 
er Console  and  the  second  as  the  Programmer /Engineer 
Console . 

The  following  paragraphs  describe  the  design  and  function 
of  a Dispatcher's  Console  and  a Pragraramer /Engineer  Console, 
utilizing  a two  CRT  console  and  a single  CRT  console 
respectively.  To  make  this  configuration  viable,  the 
optional  Keyboard/Fun ct ion  Panel  or  a third  two  CRT  console 
would  be  required. 

a.  System  Dispatcher  Console 

One  operating  console  would  be  provided  for  the  System 
Dispatcher's  interface  to  the  ECS.  The  console  would 
contain  two  CRTs,  with  a function  pushbutton  panel, 
cursor  control,  and  keyboard, located  directly  in  front 
of  and  below  the  CRT  faces.  The  characteristics  of  the 
Vendor's  standard  equipment  will  have  a significant 
effect  on  the  final  arrangement  of  the  console,  but  it 
should  be  designed  to  allow  two  men  to  operate  it  in 
an  emergency. 

Telecommunication  equipment  will  be  provided  in  the 
form  of  an  integral  ’’Call  Director"  dial  system, 
mounted  on  the  console.  The  equipment  will  be  config- 
ured to  allow  use  of  a conventional  hand  set  or  a 
lightweight  headphone  at  the  Dispatcher's  discretion. 

The  console  should  be  rigidly  constructed  to  provide 
adequate  workspace  for  Dispatchers,  storage  space  for 
books  and  reference  material,  voice  communication 
facilities,  calculator,  and  drawer  space.  Writing  areas 
should  be  scratch,  glare,  and  burn  resistant.  Lighting 
reflections  from  CRT  screens  and  other  working  surfaces 
are  unacceptable.  The  project  staff  will  be  required 
to  coordinate  the  console  design  with  the  facility 
architect  to  ensure  adequate  lighting  levels  on  work 
spaces  without  inducing  glare  on  the  CRT  displays.  A 
Dispatcher's  movements  between  telecommunication 
facilities,  CRT,  keyboard  and  writing  surfaces,  should 
be  unimpeded  by  vertical  supports. 

b . Programmer /Engineer /Console 

A second  console  will  be  provided  for  use  by  the  engi- 
neering staff.  The  equipment  will  be  identical  to  the 
Dispatcher  Console,  with  one  CRT  and  one  function  panel 
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and  keyboard  located  directly  below  the  CRT  screen. 

The  control  system  engineers  will  be  adding  new  RTUs, 
modifying  CRT  formats.,  and  incorporating  new  functions 
on  a continuing  basis,  throughout  the  life  of  the 
system.  Time  for  design  effort,  testing, and  changes 
will  be  reduced  to  a minimum  with  properly  implemented 
support  resources.  The  console  will  be  used  to  build 
CRT  displays,  add  to  the  system  data  base,  test  new 
application  software,  and  will  be  used  extensively 
when  testing  new  remote  terminal  units  or  point 
additions.  The  panel  and  CRT  are  necessary  to  simulate 
System  Dispatcher  interaction  before  activating  ad- 
ditional programs  for  normal  on-line  use. 

Preventive  maintenance,  and  rapid  correction  of  random 
system  malfunctions  require  a comprehensive  mainten- 
ance facility.  The  Programmer/Engineer/Training 
facilities  will  be  used  to  initiate  on-line  and  off- 
line diagnostics  and  monitor  normal  operation,  and  can 
be  used  As  an  operating  console  in  emergencies, or  when 
the  Dispatcher  Console  is  down  due  to  equipment 
failure . 

The  Programmer/Engineer  Console  will  be  functionally 
identical  to  the  Dispatcher  Console  and  can  be  used 
for  System  Dispatcher  training.  The  trainee  can  exe- 
cute all  normal  operations  such  as  initiating  control, 
changing  limits,  reacting  to  simulated  alarms,  and 
other  normal  functions.  While  in  training  mode,  the 
real-time  system  will  be  protected  against  inadvertent 
control  o.f  actual  system  points.  This  console  could 
also  be  used  as  a public  information  vehicle  for 
visitors . 

5 • Alarming 

Although  both  CRTs  at  a console  station  are  interchange-, 
able,  it  is  expected  that  one  CRT  will  normally  be  assign- 
ed as  the  Off  Normal  display.  Particular  care  should  be 
exercised  in  designing  this  display  which  will  be  used 
continuous  use.  Alarms  should  be  divided  into  three 
priorities:  (l)  class  1 alarms  (high  priority  electric 
system  alarms),  (2)  class  2 alarms  (low  priority  electric 
system  alarms),  and  (3)  general  computer  system  alarms. 

CRT  and  logger  messages  should  indicate  the  priority  of 
any  alarm. 
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Associated  with  the  Off  Normal  Display  are  two  alarm 
devices.  A single-stroke  audible  alarm, and  a console 
light.  On  the  occurence  of  a new  alarm  the  console  light 
will  be  switched  on.  The  single-stroke  audible  annuncia- 
tion should  be  activated  only  upon  the  occurence  of  class 
1 alarms.  A new  alarm  should  also  appear  flashing  on  the 
CRT  screen.  The  console  light  remains  lighted  until  the 
alarm  is  acknowleged.  The  new  alarm  message  appearing  on 
the  CRT  will  turn  steady.  The  only  method  by  which  alarms 
may  be  removed  from  this  display,  is  by  elimination  of  the 
alarm  condition  itself.  Alarm  messages  appearing  on  the 
CRT  should  be  "acknowledged"  by  use  of  the  cursor  and 
input  capabilities  of  the  CRT.  If  the  space  allotted  to 
alarms  is  insufficient  to  hold  the  full  set  of  undeleted 
alarms,  the  condition  should  be  indicated  at  the  bottom  of 
its  section,  and  a method  provided  to  call  up  additional 
pages  to  display  all  current  alarms  within  the  alarm 
buffer.  A history  of  alarms  should  be  printed  on  the 
system  alarm  as  they  occur,  and  will  also  be  retained  in 
the  Events  Display  until  displaced  by  subsequent  events. 

In  addition  to  the  undeleted  alarms  contained  on  the  CRT, 
the  display  should  also  include  status  conditions  which 
differ  from  their  predefined  "normal"  state  (i.e.,  a 
breaker  which  has  been  commanded  open  for  line  maintenance). 
The  Off  Normal  Display  may  be  used  by  Dispatchers  at  the 
changing  of  shifts,  to  provide  a easily  understood  descrip- 
tion of  the  current  state  of  the  power  system  operation. 

6 . Recording  and  Indicating  Devices 

Chart  recorders  and  analog  indicating  meters  are  often 
utilized  by  the  System  Dispatcher  as  the  primary  method 
of  monitoring  important  system  parameters,  and  for  histor- 
ical record  purposes.  If  this  procedure,  however,  is 
carried  to  an  extreme,  it  results  in  so  large  a number  of 
devices  that  it  is  impossible  to  assimilate  the  informa- 
tion provided.  It  is  recommended  that  a small  number  of 
these  devices  be  incorporated  for  critical  parameters. 

Other  values  may  be  viewed  on  the  CRTs.  If  hard-copy  or 
continuous  viewing  of  a particular  parameter  is  required, 
the  variable  may  be  assigned  to  one  of  several  recorders. 

The  dedicated  strip  chart  recorders  should  monitor  critical 
system  variables.  These  recorders  should  be  located 
adjacent  to  the  console  to  provide  easy  viewing  by  the 
System  Dispatcher. 
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The  system  requirements  may  also  call  for  recorders  for 
Dispatcher-designated  trending  purposes.  This  allows  the 
System  Dispatcher  to  observe  long-term  trends,  and  to  an- 
alyze in  detail,  a short-term  phenomenon.  Any  telemetered 
point  and/or  calculated  value  in  the  data  base  may  be 
designated  for  trending.  The  System  Dispatcher  should  have 
a convenient  means  to  designate  points,  delete  points, 
select  time  intervals  and  scaling,  and  to  designate  re- 
corder channels.  A CRT  display  will  be  used  to  specify  the 
assignment  and  the  range  of  the  recorder  scale.  Once  this 
data  is  entered  by  the  Dispatcher,  this  display  will 
retain  the  information  until  changed  and  serve  as  a legend 
to  identify  various  charts  to  other  System  Dispatchers,  or 
to  refresh  the  memory  of  the  System  Dispatcher  who  initiat- 
ed the  request. 

7 • Printing  Devices 

The  system  should  include  provision  for  printers  to  provide 
hard  copy  records  of  a variety  of  system  events.  There 
is  the  need  for  two  printers  as  follows: 

° Events  Printer:  System  events,  alarm  messages, 

operator  console  actions,  etc. 

0 Reports  Printer:  Reports  generated  by  application 

programs  and  resource  utilization 
programs 

These  printers  should  .be  located  away  from  the  vicinity 
of  the  consoles  to  reduce  the  noise  level  in  the  immediate 
area  of  the  Dispatcher.  The  Events  Display  can  be  used  by 
the  Dispatcher  to  examine  recent  events,  thus  removing  the 
need  to  have  the  printers  in  proximity  to  his  normal 
station.  A high  speed  line  printer  will  be  located  in  the 
computer  room  for  use  by  programmers  during  the  assembling 
and  compilation  of  new  programs.  It  may  also  be  used  as  a 
logging  printer  if  the  particular  report  is  not  directed 
to  the  System  Dispatcher.  Software  used  to  drive  printers 
should  be  general  purpose  and  be  capable  of  directing  re- 
ports and  messages  to  a designated  back-up  printer  if  the 
normal  unit  fails. 

8.  Expansion  Capability 

The  computer  system  must  satisfy  both  immediate  man/machine 
interface  requirements  and  the  projected  needs  of  the 
power  system.  The  flexibility  of  a computer-based  CRT 
system  inherently  satisfies  these  requirements.  Expansion 
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is  achieved  by  enlarging  the  computer  system  data  base  and 
adding  new,  or  modifying  existing  display  formats.  Physical 
change  of  the  man/machine  interface  is  avoided  by  utilizing 
existing  CRT  screens.  This  flexibility  does  not,  however, 
preclude  additions  to  the  physical  resources  of  the  system. 
New  CRTs  may  be  added,  new  functions  augmented,  or  existing 
functions  subdivided.  Console  steelwork  construction  should 
be  modular  and  floor  space  allotments  must  anticipate 
growth. 

Identification  of  future  requirements  is  necessary  so  that 
the  Vendor  may  initially  configure  his  system  for  probable 
expansion  in  main  memory,  auxiliary  memory  and  I/O 
channel  capability.  Software  architecture  must  be  suffi- 
ciently modular  to  facilitate  additions  without  major 
disruption,  or  costly  restructuring  of  the  initial  system. 
All  changes  should  be  made  on-line  without  interference  or 
risk  of  outage  of  the  existing  system. 

E . Facility  Requirements 

This  section  provides  for  consideration  in  planning  control 
system  facility.  It  is  intended  as  a guide,  presenting  only 
the  requirements  for  housing  the  control  equipment  and 
directly  related  personnel.  Some  Borrowers  have  experienced 
reduced  control  system  availability  and  maintenance  difficul- 
ties due  to  insufficient  space  allocation,  power  system 
supply,  and  environmental  control  equipment  capacity.  The 
descriptions  presented  here  are  representative  of  typical 
installations  developed  from  an  analysis  of  the  character- 
istics of  other  control  centers.  The  final  building  config- 
uration must  also  include  normal  architectural  and  safety 
considerations.  Consultation  with  personnel  responsible  for 
building  architecture,  equipment  suppliers,  and  staff 
engineers  will  be  necessary,  to  prepare  detailed  specifications 
for  lighting,  acoustics,  fire  prevention,  security  systems, 
air  conditioning,  uninterruptable  power  supplies,,  and  electrical 
interference.  Four  general  topics  are  discussed  in  the  follow- 
ing paragraphs:  (l)  physical  characteristics,  (2)  security, 

(3)  environmental  characteristics,  and  {h)  power  conditioning. 

1 . Physical  Characteristics 

This  section  will  describe  the  various  rooms  required  in 
the  control  center,  their  approximate  size  and  relationship 
to  one  another.  Five  areas  of  the  facility  have  been  ident- 
ified: (l)  System  Control  Room,  (2)  Equipment  Room, 

(3)  Programming  Facility,  (U)  Office,  Maintenance  and 
Storage  Facilities,  and  (5)  Power  Supply  Area. 
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Important  considerations  include  plans  for  moving  new 
equipment  into  place  and  the  free  movement  of  maintenance 
equipment  and  supplies  inside  the  various  areas.  At  least 
one  set  of  high  double  doors  with  outside  access  should 
be  considered.  The  most  severe  moving  problems  to  be 
anticipated  will  involve  the  transporting  of  multi-bay 
electronics  racks  which  cannot  be  tipped  substantially 
off  the  vertical. 

a.  System  Control  Room 

The  system  control  room  contains  the  dispatcher  con- 
trol console,  system  mapb oar d,  printers,  recorder 
boards,  and  a small  amount  of  interface  electronics. 

A minimum  area  of  h2  sq.  meters  will  allow  adequate 
space  for  a single  dispatcher  console,  and  an 
optional  second  console,  loggers,  and  a conference/ 
work  table.  A high  ceiling  (3-7-^. 6 m)  may  be  required 
in  this  room  if  a system  mapboard  is  included.  A 
false  flooring  of  . 6x . 6 m removab le  panels,  .3  meters 
high,  should  be  provided  throughout  this  area  to 
support  equipment, and  allow  hidden  routing  of  electric- 
al cables.  The  distance  of  computer  driven  equipment 
from  the  equipment  room  should  not  exceed  b6  meters 
( 60  cable  meters). 

b . Equipment  Room 

The  control  computers,  input/output  interfaces,  and  the 
bulk  of  the  auxiliary  electronic  equipment  will  be 
located  in  this  room.  A 90  square  meter  area  with 
a 2.7  meter  ceiling,  is  adequate.  The  shape  of  the  roan 
is  not  critical.  It  is  advisable  to  allow  a generous 
margin  for  future  expansion  in  these  rooms.  Working 
space  (desks  and/or  tables)  for  two  programmers/ 
engineers  should  be  available  in  this  room.  A one  foot 
high  false  flooring  of  . 6x.6  m removable  panels 
is  needed  throughout.  The  conputer  room  need  not  be 
located  at  the  same  level  as  the  control  rocm. 

However,  it  should  be  in  proximity  to  the  control 
room  to  minimize  cable  lengths.  Cable  troughs  should 
be  provided,  to  allow  routing  of  cables  between  the  two 
rooms  beneath  the  false  flooring.  To  facilitate  en- 
vironmental control,  this  room  is  usually  located 
in  the  center  of  the  building.  When  located  on  an 
exterior  wall,  suitable  insulation  must  be  provided 
to  permit  close  control  of  temperature  and  humidity. 
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c . Programming  Facility 


The  purpose  of  the  programming  facility  is  to  provide 
a convenient  location  where  new  programs  can  he 
assembled,  compiled,  debugged,  and  integrated  into  the 
system,  new  applications  can  be  formalized  by  engineers, 
and  system  dispatchers  trained.  The  area  will  be  used 
to  modify  existing  functions  or  add  new  functions  to 
the  system. 

The  facility  should  contain  a Programmer /Engineer / 
Training  Console.  Visual  access  to  the  system  control 
room  is  necessary,  if  the  console  is  to  be  used  as  a 
second  dispatcher  console  during  stress  periods. 

Access  to  the  control  room  and  computer  peripherals 
is  required.  Approximately  IT  sq.  meters  of„.space  will 
be  required. 

d.  Office,  Maintenance,  and  Storage  Facilities 

It  is  recommended  that  all  system  control  personnel 
have  their  offices  near  the  control  center  itself. 

The  allocation  of  maintenance  areas  depends  heavily  on 
the  relative  arrangement  of  other  control  center 
rooms.  A minimum  of  18  sq.  meters  is  recommended.  The 
final  arrangement  should  provide  for  rapid  movement 
of  test  equipment  from  the  maintenance  area  to  the 
equipment  room. 

Three  types  of  storage  facilities  should  be  considered. 
These  could  be  combined  into  a single  roam,  or  divided 
into  separate  areas.  They  are:  (l)  spare  parts, 

(2)  consumable  supplies  such  as  printer  paper,  chart 
paper  and  ribbons,  and  (3)  protected  storage  of  source 
programs,  data,  etc.  Spare  parts  should  be  stored  in 
closed  containers  - e.g.,  utility  cabinets,  in  the 
maintenance  area.  Consumables  can  be  stored  on  open 
shelving,  or  stacked  on  the  floor  on  shipping  pallets. 

An  additional  5 sq.  meters  of  floor  area  will  be 
adequate  for  this  function.  Protected  storage  should 
be  fireproof  and  tamperproof.  Individual  safes  may  be 
used,  but  because  of  the  variety  of  shapes  and  sizes 
of  computer  records,  a single  vault  with  appropriate 
racks,  files  and  shelves,  is  preferable.  Approximately 
5 sq.  meters  of  floor  area  should  be  provided  for  this 
function. 
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e.  Power  Supply  Area 


The  uninterruptible  power  supply  and  other  power 
conditioning  equipment  require  a separate  area.  A 
minimum  of  lU  sq.  meters  is  required  for  the  battery, 
charger, and  inverter.  This  equipment  should  be  sound 
isolated  because  of  inverter  hum,  and  located  in  an 
air  conditioned  portion  of  the  building.  OSHA  re- 
quirements must  be  met  in  storage  battery  areas  in- 
cluding venting  and  eye-wash  facilities.  A back  up 
motor  generator  set  and  electrical  switchgear  could 
also  be  located  external  to  the  building.  Such 
equipment  should  be  isolated  from  the  electronic 
equipment  areas  because  of  possible  noise,  vibration, 
and  electromagnetic  interference.  The  required  floor 
space  will  depend  on  a detailed  analysis  of  total 
facility  power  requirements. 

2.  Se curity 

Two  aspects  of  the  security  are  discussed  in  this  section: 
(l)  access  to  the  area,  and  (2)  smoke  and  fire  protection. 
The  facility  should  incorporate  sensors  providing 
warnings  of  all  types  of  violations  to  area  security  and 
their  location. 

a.  Area  Access 

The  control  center  contains  valuable  and  vulnerable 
equipment  which  must  be  protected  from  intentional 
and  accidental  abuse.  The  tasks  being  performed  by  the 
system  dispatcher  necessitate  protection  from  un- 
necessary distractions  caused  by  unauthorized  personnel 
in  this  area.  For  these  reasons,  access  to  the  control 
systems  should  be  restricted.  A single  entry  point 
with  cipher /key  lock  or  under  the  control  of  the 
system  dispatcher  is  recommended.  All  other  doors 
to  the  facility  area  should  be  sealed  in  conformance 
with  local  fire  regulations.  It  would  also  be  advis- 
able to  sense  the  status  of  these  doors,  and  trigger 
an  alarm  when  one  of  them  is  opened. 

b.  Smoke  and  Fire  Protection 


The  smoke  and  fire  protection  system  performs  three 
principal  functions:  (l)  early  detection  of  fire,  and 
delivery  of  a warning  to  employees  so  that  an  attempt 
at  hand  extinguishing  can  be  made,  (2)  detection  of 
an  advanced  fire  condition  and  automatic  extinguishing. 
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and  t(3)  warning  to  employees  to  evacuate  the  facility. 
Smoke  and  fire  protection  for  the  equipment  area  is 
particularly  important  during  off-hours,  since  they 
may  be  out  of  view  of  control  room  personnel.  The 
details  of  the  final  system  depend  on  the  architec- 
tural characteristics  of  the  building.  The  National 
Fire  Code  and  local  fire  and  safety  regulations  may 
be  consulted  to  determine  specific  design  criteria. 

Early  detection  of  fire  can  be  accomplished  by  a 
variety  of  smoke  detectors.  The  bulk  of  these  should 
be  located  below  the  false  flooring  where  computer 
room  fires  most  often  originate.  Some  may  also  be 
located  above  floor  level.  Smoke  detection  should 
sound  a distinctive  alarm  and  give  a clear  indication 
of  the  location  of  the  activated  sensor.  Hand  fire 
extinguishers  should  be  located  throughout  the  area 
according  to  local  codes.  The  smoke  alarm  should  also 
sound  in  the  control  room. 

The  detection  of  a general  fire  condition  is  usually 
accomplished  with  thermal  sensors  located  in  the 
ceiling.  These  sensors  should  trigger  a fire  extinguish- 
ing system  in  the  area  in  which  the  fire  is  sensed. 

The  fire  alarm  should  trigger  an  evacuation  alarm 
within  the  facility  and,  if  permitted,  automatically 
alert  local  fire  authorities. 

3 • Environmental  Characteristics 

This  section  describes  the  environment  suitable  for  the 
equipment  and  personnel  of  the  control  system.  The 
following  topics  will  be  discussed:  (l)  air  conditioning, 

(2)  acoustics,  (3)  lighting,  and  (U)  electrical  inter- 
ference . 

a.  Air  Conditioning 

Severe  air  conditioning  demands  are  made  by  the  comput- 
er room  equipment.  This  type  of  equipment  is  sensitive 
to  humidity  deviations  and  static  charges  accompanying 
low  humidity.  Computer  manufacturers  typically  claim 
broad  limits  over  which  their  equipment  will  operate 
satisfactorily.  Experience  has  shown,  however,  that 
availability  of  computer  equipment  suffers  appreciably, 
when  even  small  deviations  from  nominal  values  occur. 

The  computer  room  environment  should  be  rigidly  main- 
tained. Consideration  should  be  given  to  establishing 
some  level  of  redundancy  in  the  air  conditioning 
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system  to  avoid  heat  excursions  in  the  event  of  loss 
of  a single  unit . 

It  is  recommended  that  separate  air  conditioning  units 
be  utilized  to  maintain  the  equipment  room  at  22  - 1°C 

and  50%  ± 5%  relative  humidity.  The  load  will  probably 

not  be  uniformly  distributed  throughout  the  room,  so 
that  provision  must  be  made  for  directing  the  flow  of 
air  to  high  heat  concentrations.  The  use  of  the  under 
floor  space  as  a plenum  is  one  approach  to  this 
problem.  A positive  pressure  should  be  maintained  in 
the  room,  using  filtered  air  to  avoid  excessive  dust 
and  dirt. 

The  power  supply  room  is  a relatively  small  room  with 
high  heat  loads.  Dissipation  of  approximately  U0,000- 
70,000  BTU/Hr  can  be  expected.  The  load  is  predominant- 
ly sensitive  to  heat.  Temperature  control  can  be  some- 
what relaxed  from  other  areas  with  l8°C  to  27°C  being 
acceptable.  Humidity  control  is  not  critical. 

The  remainder  of  the  control  system  can  be  controlled 
by  conventional  means.  The  control  requirements  are 
dictated  by  personnel, rather  than  equipment  needs 
( 22°±  1°F  and  b0%>  +10 % relative  humidity) . 

b.  Acoustics 


In  areas  where  professional  personnel  are  working, 
interior  building  materials  should  be  selected  on  the 
basis  of  sound  attenuation  characteristics.  Carpeting 
throughput  the  facility  provides  an  additional  source 
of  sound  attenuation.  A goal  of  50  db  maximum  through- 
out the  facility  should  be  used.  Special  consideration 
is  necessary  in  the  computer  room.  Because  of  the  high 
capacity  cooling  system  required,  high  volume  air 
flows  may  also  create  noise.  Sound  attenuating  baffles 
are  available  and  should  be  specified  in  consultation 
with  the  architect.  A high  concentration  of  equipment 
with  cooling  fans  will  raise  the  noise  level  in  the 
equipment  rooms,  though  not  beyond  acceptable  levels. 
Necessary  peripherals  with  high  noise  levels  should  be 
provided  with  acoustical  enclosure. 

c . Lighting 

A general  level  of  approximately  75  foot-  candles  of 
diffuse  fluorescent  illumination  is  recommended 
throughout  the  facility.  Care  should  be  taken  to  pre- 
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vent  glare  on  the  CRTs  from  general  room  lighting. 
Special  provision  must  he  made  for  dimming  lights  in 
rooms  with  system  dispatcher  consoles.  Local  switches 
should  be  provided  to  extinguish  the  fluorescent  light 
ing  in  a minimum  of  three  stages,  while  still  maintain- 
ing uniform  illumination,  or  to  turn  lighting  off 
completely.  Each  system  dispatcher  station  should  be 
provided  with  an  additional  50  foot-candles  of 
direct  incandescent  illumination  which  can  be  dimmed 
from  0 to  100%  in  a continuous  fashion.  It  may  prove 
to  be  more  convenient  if  local  lighting  could  be  con- 
trolled at  individual  dispatcher  stations. 

d.  Electrical  Interference 


Interference  problems  can  become  very  complex,  and 
must  usually  be  evaluated  in  the  context  of  specific 
equipment  arrangement,  cable  runs  and  power  dis- 
tribution. Interference  problems  produced  by  the 
facility  can  usually  be  predicted  and  avoided  in  ad- 
vance. Electrostatic  discharge  between  personnel  and 
equipment  can  cause  disturbances  in  computer  circuitry 
Two  precautions  are  helpful  in  solving  this  problem: 

(1)  maintenance  of  acceptable  levels  of  humidity,  and 

(2)  the  selection  of  static-free  materials  for  use  in 
these  areas.  Anti-static  carpeting  should  be  used  in 
the  control  center  and  throughout  the  facility. 
Similarly,  anti-static  fabrics  should  be  specified  for 
coverings  on  any  furnishings  in  the  area.  Incandescent 
lighting  is  recommended  where  dimming  is  necessary. 
Dimming  controls  should  be  of  the  autotransformer  type 

U . Power  Conditioning 

The  following  paragraphs  discuss  the  power  supply,  dis- 
tribution, redundancy,  and  the  grounding  required. 

a.  Power  Supply 

Because  of  the  importance  and  uninterruptible  nature 
of  system  control  operations,  substantial  redundancy 
should  be  designed  into  the  control  equipment.  A 
corresponding  level  of  redundancy  should  be  provided 
in  the  power  source  to  assure  an  uninterrupted  flow 
of  conditioned  power.  To  satisfy  system  reliability 
requirements,  the  power  supply  configuration  should  be 
comprised  of  two  independent  distribution  lines,  a 
solid-state  uninterruptible  power  supply  subsystem, and 
an  emergency  engine  generator.  The  power  supply  system 
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should  he  sized  to  accommodate  both  present  and  future 
requirements. 

b . Grounding 

The  physical  characteristics  of  the  ground  network 
depend  heavily  on  the  arrangement  and  characteristics 
of  the  equipment  purchased.  The  supplier  of  the  control 
center  devices  may  specify  a ground  network  to  be 
installed  on  the  building  floor.  A single  earth  ground 
will  be  necessary  for  signal  grounds.  All  signal 
grounds  should  be  connected  to  this  point,  either  by 
a radial  network,  or  a point  to  point  system.  Equip- 
ment with  ground  busses  in  each  cabinet  will  reduce 
the  complexity  of  the  grounding  network.  For  initial 
purposes,  it  will  suffice  to  provide  a low  impedance 
connection  to  earth  at  each  of  the  main  power  dis- 
tribution boxes. 
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F.  Staffing  and  Training 


Computer  systems  of  the  scope  described  herein  require  a full- 
time senior  engineer  completely  responsible  for  all  phases  of 
the  project.  During  the  preparation  of  the  specification  and 
the  evaluation  of  proposals  this  engineer,  the  Project 
Manager,  will  require  support  from  several  specialized  tech- 
nical disciplines.  The  project  team  should  include,  as  a min- 
imum, personnel  having  experience  in  the  details  of  the  gen- 
eration and  sub-transmission  network,  modern  digital  hardware, 
and  real-time  programming.  After  contract  award,  during 
implementation  of  the  system  and  until  the  completion  of  ac- 
ceptance tests,  the  expertise  demanded  of  the  project  team 
shifts,  requiring  the  addition  of  programmer /engineers  and 
maintenance  personnel.  Portions  of  the  project  staff  form 
the  nucleus  of  the  permanent  staff. 

1.  Project  Staffing  and  Personnel:  In  addition  to  normal 

project  duties  which  include  ensuring  Vendor  compliance 
with  the  specification,  contract  negotiation,  cost  control, 
and  project  scheduling,  the  project  team  will  be  concerned 
with  the  following  tasks : 

° Coordination  of  project  activities  with  partici- 
pating departments  and  member  cooperatives 

0 Telecommunication  har^  'are  manufacture  and  tests 

0 Conceptual  design  and  implementation  of  the 
communications  network 

° Console  design,  manufacture  and  test 

° Miscellaneous  hardware  manufacture  and  tests 

° RTU  manufacture  and  tests 

° Scheduling  of  deliveries  of  equipment  and  applica- 
tion programs 

0 Software  development 

° Integrated  hardware  and  hardware /software  tests 

° Site  preparation,  consultation  with  architects  and 
interior  designers 

° Installation 
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Field  tests  and  availability  tests 
° Start  up 

a.  Project  Manager:  The  Project  Manager  is  responsible 
for  the  specification  and  procurement  of  a system  that 
will  eventually  control  and  monitor  all  of  generation, 
sub-transmission  equipment,  and/or  distribution 
system.  The  Project  Manager  should  be  a senior  engi- 
neer having  working  knowledge  of  the  equipment  and  its 
interrelations  with  the  operations  of  the  entire  co- 
operative. Supported  by  specialists  on  the  project 
team,  this  individual  would  also  require  familiarity 
with  the  characteristics  and  limitations  of  the  hard- 
ware and  software  currently  employed  by  Vendors  to 
implement  energy  control  systems.  The  Project 
Manager’s  commitment  to  the  project  must  be  full-time 
from  the  planning  stage  through  acceptance  testing. 

His  activities  should  be  divided  equally  between  man- 
agement responsibilities  and  assisting  in  the  software 
efforts.  Project  Manager  tasks  will  include: 

° Overall  coordination  of  project  team  manpower 
0 Monitoring  Vendor  performance 
° Liason  with  the  building  architects. 

° Conducting  project  review  meetings 
° Maintaining  the  project  schedule 
° Aiding  in  the  data  base  implementation 

The  Project  Manager  can  be  expected  to  be  committed 
for  the  full  course  of  the  project. 

b.  Engineering  Support:  Distinct  areas  of  expertise  can 

be  identified  within  the  project  team’s  engineeering 
staff.  Each  area  will  require  a general  electrical 
engineering  background  supported  with  specialized 
application  experience.  Tasks  to  be  covered  by  the 
engineering  staff  include: 

° Monitoring  the  Vendor" s implementation  of 
hardware  and  software 

° Supplying  the  Vendor  with  specific  data  base 
documentation 
° Approving  CRT  formats 
° Designing  all  RTU  installations 
° Designing  the  communications  system 
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The  specification,  monitoring  and  approval  of  Vendor 
supplied  hardware  and  software  should  he  accomplished 
by  an  engineer  with  experience  in  the  characteristics 
of  real-time  systems.  The  responsibilities  of  the 
Digital  Systems  Engineer  will  require  a full-time 
commitment  to  the  project,  initiating  at  the  time 
of  contract  award.  Early  in  the  implementation  phase 
of  the  project  this  individual  should  attend  the  per- 
tinent courses  offered  by  the  Vendor  covering  the 
operation  of  the  system  hardware  and  software.  The  en- 
gineer's project  responsibilities  will  include 
evaluation  of  Vendor-supplied  non-standard  hardware 
and  configurations,  approving  system  test  procedures, 
aiding  in  the  data  base  implementation,  specifying 
and  reviewing  man-machine  interface  operation  and 
participation  in  system  testing  at  the  Vendor's 
facility. 

Any  project  needs  concerning  detailed  information 
about  generating  units,  substations  or  other  equipment 
should  be  the  responsibility  of  a Power  Systems  Engi- 
neer. Additional  responsibilities  include  the  de- 
sign of  RTU  installations,  and  coordination  of  the 
interfaces  with  other  power  systems.  This  function 
will  require  full-time  commitment  up  to  the  time  of 
system  operation,  and  part-time  involvement  after 
this  point  to  coordinate  the  system  configuration. 

A third  engineer,  working  on  a half-time  basis  will  be 
necessary  after  contract  award.  This  position,  the 
Communications  Engineer,  will  be  responsible  for  the 
design  and  implementation  of  the  communications 
system. 

A small  drafting  and  clerical  staff  is  required  to  aid 
the  engineering  staff. 

After  acceptance  these  individuals  will  be  responsible 
for  directing  and  supervising  the  activities  of 
computer  programming,  hardware  maintenance  and  general 
system  related  operations  at  the  Energy  Control 
System. 

c.  Operations  Support:  The  Manager  of  Operations  should 

assign  a representative  to  the  project  to  ensure  that 
the  control  room  equipment  and  services  are  designed 
to  provide  optimum  service  to  the  System's  Dispatchers 
and  promote  Dispatcher  acceptance  of  the  new  system. 
The  computer  project  will  require  this  individual  on 
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a half-time  schedule  to  design  and  review  formats  for 
all  man-machine  interfaces  including  .logging,  trending 
and  display  requirements.  These  functions  will  be 
accomplished  in  parallel  to  this  individual's  main 
task  of  designing  the  operating  procedures. 

The  individual  will  be  required  to  attend  Vendor 
training  courses  covering  the  operation  of  the  system. 
This  information,  and  the  final  operations  documenta- 
tion will  be  used  in  training  the  System  Dispatchers. 

d.  Programming : One  programmer/engineer  and  the  digital 

system  engineer  should  attend  all  appropriate  courses 
offered  by  the  Vendor  early  in  the  implementation 
phase  of  the  project.  As  the  software  design  proceeds, 
these  individuals  will  provide  software  monitoring 
assistance  to  the  Project  Manager.  The  programmer/ 
engineer  should  also  be  assigned  tasks  developing 
selected  application  programs  for  the  control  center 
and  participate  in  the  integrated  system  test  of  the 
Vendor's  facility.  The  application  programs  may  be 
written  while  the  individual  is  assigned  to  the 
Vendor ' s plant . 

e.  Maintenance : The  experience  of  utilities  with  control 

systems  shows  that  in-house  maintenance  capability  is 
superior  to  complete  reliance  on  Vendor  field  support 
to  achieve  the  high  availability  required.  Utility 
personnel  respond  faster  to  isolate  hardware  problems 
and  restore  system  operations  when  failures  occur. 
Familiarity  with  the  actual  installation  and  continual 
performance  monitoring  allows  company  personnel  to  de- 
tect and  remedy  incipient  hardware  problems  before 
they  result  in  system  failures.  Vendors,  by  contrast, 
normally  concentrate  their  system  maintenance  engi- 
neers at  headquarters.  Additional  time  and  costs  are 
spent  to  effect  most  repairs.  Constant  maintenance  by 
dedicated  Vendor  personnel  on  the  other  hand  would  be 
far  too  costly.  The  Borrower  should  perform  all  main- 
tenance and  rely  on  the  Vendor  only  for  extremely 
difficult  failures  and  the  repair  of  complex  system 
elements . 

The  maintenance  of  the  master  station  should  be  the 
responsibility  of  highly  motivated,  well- trained 
personnel.  The  maintenance  of  computer  equipment 
require  skills  beyond  those  of  average  technicians. 
Once  trained,  computer  maintenance  men  are  in  great 
demand  in  industry,  and  the  borrower  must  make  this 
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position  an  attractive  one  for  competent  individuals. 
Two  master  station  maintenance  technicians  are  requir- 
ed to  provide  round-the-clock  on-call  support,  and  to 
assure  that  if  one  key  man  is  not  available,  or  seeks 
another  position  the  system  will  not  be  subjected  to 
loss  of  all  preventive  and  repair  maintenance.  Both 
individuals  should  attend  all  available  courses  cover- 
ing hardware,  diagnostic  software, and  communication 
equipment  offered  by  the  Vendor  during  the  implement- 
ation phase  of  the  project. 

In  addition,  on-site  RTU  installation  and  maintenance 
training  should  be  conducted  for  the  two  maintenance 
engineers  and  a maximum  of  six  individuals  who  will  be 
used  to  maintain  RTU^  located  at  distant  sites.  It  is 
recommended  that  a minimum  of  three  remote  maintenance 
sites  be  established,  to  be  staffed  by  the  six  RTU 
maintenance  technicians,  and  that  these  sites  be 
equipped  with  test  equipment  and  spare  parts  suffi- 
cient to  accomplish  normal  repairs.  Personnel  for 
this  function  could  be  drawn  from  the  maintenance 
staffs  of  the  member  co-ops. 

Valuable  additional  training  is  available  during 
checkout  of  various  subsystems  during  system  integra- 
tion prior  to  acceptance  testing.  Maintenance  per- 
sonnel are  expected  to  play  an  active  role  in  system 
testing  at  the  Vendor's  facility,  and  in  installation 
and  acceptance  testing.  Maintenance  personnel  will 
report  to  the  digital  systems  engineer  on  the  Project 
Manager's  staff. 

f.  Consultants : If  the  Borrower  is  unable  to  provide  the 

full  project  staff,  consideration  should  be  given  to 
the  use  of  consultants  to  supplement  the  available 
manpower.  Three  reasons  make  this  approach  feasible: 
(l)  it  eases  manpower  requirements  during  the  diffi- 
cult early  months  of  the  project;  (2)  allows  the 
timely  completion  of  the  project  without  costly  delays 
resulting  from  lack  of  personnel  for  design  and/or 
monitoring  purposes;  and  (3)  the  consultant  brings 
to  the  project  an  objective  knowledge  of  the  Vendors 
and  their  systems  based  on  the  wide  experience  of 
its  staff  which  can  be  acquired  in  almost  no  other 
way. 


The  Borrower  should  consider  utilizing  consultants  to 
provide  expertise  in  these  specific  areas; 
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Preparation  of  the  specification,  Vendor 
evaluation,  and  negotiation 
° Planning,  specifying  and  implementing  the 
communications  network 
° Monitoring  the  Vendor's  progress  in  soft- 
ware 

° Project  overview  - utilizing  consultant's 
experience  on  similar  projects  to  monitor 
Vendor  performance 

Consultants  should  be  considered  a temporary  expedient, 
however,  and  in  no  way  a substitute  for  direct  Borrow- 
er involvement  in  the  design  and  implementation  of  the 
system,  or  the  Borrower's  proficiency  in  all  aspects 
of  the  system's  daily  operation.  The  lesson  learned 
expensively  by  many  utilities  is  that  a computer 
system  is  as  successful  as  their  staff's  daily  and  in- 
depth  technical  involvement  in  it.  The  computer  system 
cannot  be  considered  equipment  which,  after  careful 
specification  and  purchase,  performs,  unattended, 
until  it  is  replaced. 

2.  Permanent  System  Staffing:  Acceptance  of  the  new  system 

implies  the  existence  of  trained  personnel  to  operate, 
maintain  and  update  it.  The  basic  staff  should  consist  of 
personnel  previously  assigned  to  the  specification  and 
implementation  of  the  project.  Additional  manpower  will  be 
trained  subsequently  and  given  hands-on-  experience  with 
the  system.  After  system  acceptance,  the  control  system 
staff  should  consist  of  one  digital  system  engineer,  one 
programmer /engineer,  two  master  station  maintenance  men, 
and  six  RTU  maintenance  men  located  in  the  field.  The  on- 
going requirements  for  engineers  and  programmers  is  a 
direct  function  Of  the  development  work  the  Borrower  may 
elect  to  accomplish  in-house.  The  initial  personnel  as- 
signed to  the  permanent  staff  should  participate  in  the 
factory  acceptance  test. 

After  system  acceptance,  programming  personnel  involved  in 
the  monitoring  and  implementation  of  the  new  system  will 
continue  to  perform  daily  updating  and  longer-range  soft- 
ware development  tasks.  Sufficient  development  work  should 
remain  to  ensure  the  continued  interest  of  programming 
personnel,  and  minimize  diversions.  These  programmers  will 
report  to  the  Digital  System  Engineer. 
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3.  Training : The  training  of  borrower  personnel  should  be 

geared  to  achieve  the  following  objectives:  ensuring  the 
system's  availability  to  System  Dispatchers  by  quickly 
isolating  and  correcting  failures;  ensuring  that  backup 
devices  are  always  ready  to  assume  on-line  functions; 
permitting  expansion  and  reconfiguration  of  hardware  and 
software  to  match  the  changing  electrical  system;  and 
promoting  a thorough  understanding  of  the  capabilities  of 
the  computer  system  with  its  assigned  staff. 

Whenever  possible,  training  courses  should  be  conducted  at 
convenient  on-site  locations.  Other  locations  are  accept- 
able if  the  technical  material  can  best  be  covered  there, 
or  the  number  of  participants  is  small.  Training  should  be 
conducted  by  experienced  personnel,  supported  by  modern 
training  aids.  Individual  copies  of  technical  manuals  and 
pertinent  documentation  should  also  be  given  to  partici- 
pants at  the  time  the  course  is  conducted.  The  courses 
should  be  scheduled  in  a staggered  manner  so  that  one  man 
could  participate  in  all  of  them. 

Training  courses  and  most  participation  by  the  Borrower 
during  the  system  implementation  will  be  at  the  Vendor's 
facilities.  Detailed  schedules  of  activities  cannot  be 
predicted.  Borrower  engineers,  maintenance  personnel  and 
programmers,  with  the  exception  of  operations  personnel, 
must  be  dedicated  to  the  project  and  should  not  be 
assigned  to  other  duties  until  the  system  is  successfully 
installed. 

a.  Hardware  Maintenance  Courses:  Engineering  and  main- 

tenance personnel  should  attend  two  courses  dealing 
with  the  hardware  furnished  with  the  system.  The 
courses  should  occur  within  three  months  of  the  in- 
tegrated factory  acceptance  test.  One  course  should 
deal  with  the  computer  mainframe,  its  operation  and 
capability  as  a diagnostic  tool.  The  second  course 
should  cover  the  peripherals,  their  interface  with  the 
mainframe  and  the  operation  of  their  internal  logic, 
remote  terminal  units  and  telemetering  equipment. 

These  courses  should  be  structured  to  enable  main- 
tenance personnel  to  operate  actual  equipment,  run 
off-line  and  on-line  diagnostics  and  repair  failures. 
Additional  training  courses  provided  by  subcontractors 
should  be  attended  if  they  are  available.  This  is  of 
particular  importance  for  the  CRT  and  printer  hard- 
ware. The  latter  courses  should  be  more  detailed  and 
cover  all  aspects  of  electronic  and  mechanical 
operation . 
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b.  Software  Courses:  The  Vendor  should  provide  extensive 

software  training  for  the  project  staff.  Software 
courses  should  aim  at  familiarizing  the  staff  with  all 
aspects  of  the  systems  programming  characteristics. 
These  courses  should  begin  as  soon  as  possible  after 
award  of  contract.  Software  courses  should  be 
presented  in  three  sections: 


(1)  Acourse  covering  the  assembly  languages,  I/O 
interfaces,  debugging  tools,  and  the  operating 
system, from  the  point  of  view  of  the  program- 
mers using  the  equipment  and  software. 

(2)  A course  covering  any  high-level  programming 
languages  as  required  for  the  computers,  and 
their  interface  with  the  operating  system. 

(3)  A course  offering  a detailed  study  of  the  spe- 
cialized software  supplied  by  the  Vendor  and 
the  detailed  logical  structure  of  all  standard 
software  used  by  the  system. 

The  courses  should  foster  familiarity  with  off-line 
and  on-line  procedures  for  the  generation  of  programs, 
operation  of  peripherals,  use  of  documentation,  use  of 
the  computer  console,  start  up  and  shut-  down  proce- 
dures, and  the  use  of  off-line  and  on-line  debugging 
aids . 

c.  System  Dispatcher  Training:  The  System  Dispatcher 

training  course  should  be  divided  into  three  segments 
to  increase  involvement  and  understanding  of  the 
system  and  keep  instructional  periods  to  a minimum: 
Familiarization,  start-up  training  and  subsequent 
training.  The  familiarization  would  be  a short  course 
held  at  the  facility  thirty  to  sixty  days  before  the 
system  is  shipped.  Manuals  should  be  distributed  prior 
to  this  class.  This  course  will  introduce  system  con- 
cepts and  general  design  features  to  the  System  Dis- 
patchers. The  project  staff  would  be  the  best  equipped 
to  conduct  this  and  subsequent  System  Dispatcher 
training  courses. 

During  installation  and  start  up, the  second  section 
of  the  course  should  be  given.  This  course  will  in- 
elude  hands-on  operation  of  all  equipment,  and 
practice  in  the  procedures  required  to  perform  various 
tasks.  To  increase  the  usefulness  of  the  system  during 
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this  period,  a special  training  mode  will  be  provided. 
This  training  mode  would  allow  access  to  any  CRT  dis- 
play and  CRT  changes  to  a substation  or  functional 
display,  without  transmitting  commands  or  otherwise 
distributing  the  RTUs. 

After  the  system  has  been  accepted  and  is  in  operation, 
a continuing  training  program  will  be  initiated.  New 
System  Dispatchers  will  be  trained  using  the  Program- 
mer/Engineer/Training Console.  In  the  training  mode, 
the  system  will  provide  all  console  functions, except 
control  actions> which  affect  the  power  system.  As  new 
functions  are  added  to  the  system,  the  System  Dis- 
patchers will  be  trained  in  their  use  without  jeopard- 
izing the  security  of  operation. 

The  courses  should  be  conducted  by  the  operations  re- 
presentative assigned  >to  the  project  staff.  This  in- 
dividual will  require  training  from  the  Vendor  in  the 
initial  phases  of  the  project,  sufficient  to  allow 
preparation  of  the  course  material  to  be  presented  in 
the  dispatcher  training. 


III-97 


G.  Documentation 


While  the  Vendor  is  responsible  for  the  system  operation  and 
maintenance  through  the  final  acceptance  demonstration,  it 
should  be  the  practice  during  the  latter  phases  of  the  project 
for  the  Vendor  to  use  Borrower  operations  personnel  to  the 
maximum  extent  possible  for  on-the-job  training. 

It  should  be  the  goal  of  the  Borrower  to  become  self-sufficient 
in  all  aspects  of  maintenance  as  soon  as  possible.  Until  that 
time,  it  may  become  necessary  to  contract  appropriate  levels 
of  follow-on  support  maintenance.  In  order  to  a assure  that 
the  Borrower  has  the  opportunity  to  become  self-sufficient  in 
a timely  and  orderly  manner,  it  is  necessary  that  the 
Supplier  provide  quality  documentation  and  quality  training. 
Adequate  program  management  should  be  provided, to  assure  that 
Borrower  personnel  receive  the  product  and  services  required. 

In  this  regard,  documentation  should  be  provided  which  de- 
scribes the  system  and  interfaces  in  support  of  testing, 
installation,  system  activation,  operation,  and  maintenance. 

The  requirements  for  documentation  are  discussed  in  the  fol- 
lowing sections. 

1.  System  Design  Specification 

The  Supplier  should  develop,  during  the  program  initial 
design  phase,  a detail  design  specification  which  will  be- 
come the  baseline  for  the  hardware  and  software  systems 
configuration  and  performance  to  be  delivered  in  the 
course  of  the  contract.  The  design  specification  document 
should  contain  as  a minimum: 

° Description  and  configuration  of  the  system  and 
identification  of  deliverable  hardware  and  software 
subsystems 

° Description  of  deliverable  documentation 

° System  performance  of  both  hardware  and  software 
subsystems 

0 Overall  test  and  performance  demonstration  plan, 
including  the  level  of  tests  to  be  performed  to 
assure  the  system  meets  the  stated  performance 
values 

° Detailed  description  of  system  interfaces 
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2.  Hardware  Documentation 


A hardware  documentation  package  should  be  established  to 
include : 

° Block  diagrams  showing  the  overall  system  and 
information  data  flow 

° Hardware  layout  and  assembly  drawings  showing 

equipment  arrangement,  configuration,  dimensions  of 
each  rack  cabinet,  console,  display  panel,  module, 
etc . 

° Internal  wiring  diagrams  and  listings 

° Schematic  or  logic  diagrams  of  all  modules,  panel 
assemblies,  etc. 

° Schematics  for  use  in  defining  system  operational 
modes  and  functions 

° Interface  connection  and  control  drawings,  and  wire 
point  listings  between  system  and  telephone^ and 
power  company  equipment 

° Site  preparation,  installation  drawings  and  proce- 
dures. Includes:  power,  grounding,  and  environmental 
requirements,  cable  routing,  safety  precautions  and 
equipment  handling,  procedures  for  mechanical 
assembly  of  consoles  and  racks,  list  of  installation 
tools  to  install  each  piece  of  equipment,  etc. 

3 . Software  Documentation 


A software  documentation  package  should  be  established  to 
include : 

° Program  requirement  specifications 
° Acceptance  test  procedures  and  test  reports 
° Program  description  documents 
0 Program  interface  control  documents 
0 Configuration  control  methodology 
0 Annotated  program  listing  documents 
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Maitenance  and  users  manuals 

° Source  card  decks 

° Object  card  decks,  tapes,  or  disk 

The  program  requirements  documents  should  define  "what"  is 
to  be  programmed.  The  description  documents  define"how" 
each  requirement  is  mechanized  or  implemented.  Document- 
ation detail  should  be  sufficient  such  that  a semi- 
experienced  assembly  language  programmer  can  readily 
make  modifications  to  the  system. 

Software  should  be  of  modular  construction ? with  provisions 
made  for  updating  a module  without  reassembling  the  entire 
program.  Linkage  conventions  must  also  be  standardized 
and  well  documented.  A program  listing  with  comments  does 
not  in  itself  constitute  a documented  program. 

A Software  Acceptance  Test  procedure  defines  what  con- 
stitutes acceptable  software  performance,  and  how  each 
software  package  is  to  be  tested, to  assure  proper  operation 
and  conformance  to  specification  requirements.  The  test 
reports  document  the  results  of  each  test  performed.  The 
software  descriptions  should  include  main  frame  related 
software . 

A users  manual  should  be  provided  that  contains  as  a 
minimum : 

° Description  of  the  overall  software  organization 

° Narrative  description  of  each  program 

° Instruction  language,  data  format,  and  coding 

° Program  explanatory  material  such  as  macro  and  micro 
flow  charts,  logic,  and  cross-referencing 

° File  input  and  output  requirements 

° Storage  maps 

° Interfaces  to  other  programs 
° Hardware  requirements 
° Supporting  program  requirements 
° Program  constraints 
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° System  features  and  related  materials 

0 Variable  cross-reference  tables 

4.  System  Operation  and  Maintenance  Manuals 

The  manuals  supplied  should  provide  instructions  for  the 
system  operation,  preventive  maintenance,  troubleshooting, 
and  repair.  Manuals  should  also  cover  the  following 
subject  areas: 

° Computer  subsystem  operation  and  maintenance 

° Data  acquisition  and  subsystem  operation, and  main- 
tenance 

° Man/machine  subsystem  operation  and  maintenance 

° Software  control  subsystem  programming  manuals  and 
maintenance 

0 System  operator  procedures 
0 Standard  equipment 

The  manuals  should  contain  the  following  general  topical 
structure : 

0 System  Concept,  Function, and  Interface 

General  description  of  system 
System  function  and  modes 
System  interfaces 
System  theory  of  operation 
Supplemental  system  data  and  drawings 

0 Subsystem  Concept,  Function,  and  Interface 

General  description  of  subsystem 
Subsystem  function  and  modes 
Subsystem  interfaces 
Subsystem  installation  details 
Subsystem  theory  of  operation 

Subsystem  maintenance  procedures  (as  applicable) 

Subsystem  equipment  configuration 

Equipment  manuals 

Repair  parts  identification 

Test  equipment  requirements 

Supplemental  subsystem  data  and  drawings 
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5 • Training  Documentation 


A training  program  should  be  obtained  from  the  Vendor 
detailing  individual  training  courses  as  follows: 

° Duration 

° Location 

° Qualification  of  instructors. 

0 Objectives 

° Prerequisites 

° Content 

° Outline 

° Training  materials  (handouts) 

° Audio- Visual  aids 

° Special  equipment,  tools,  etc. 

0 Ratio  of  classroom  to  hands-on  laboratory  experience 

The  basic  courses  to  be  considered  in  the  training  plan 
are : 

° Power  System  Operation  - The  instructions  on  how  to 
use  the  consoles,  CRT, and  other  man/machine  equipment 
in  the  control  room 

° Computer  System  Operation  - The  instructions  on  how 
to  operate  the  computer  system,  system  failover, 
restart  the  system,  and  operation  of  peripherals 

° Computer  and  Peripheral  Maintenance  - The  instructions 
on  how  to  maintain,  troubleshoot,  repair,  and  adjust 
the  equipment  supplied  by  the  mainframe  subcontract 
or 

° System  Hardware  Maintenance  - The  instructions  on  how 
to  maintain,  troubleshoot,  repair,  and  adjust  the 
remainder  of  the  hardware  supplied  at  the  system 
operations  center,  including  such  items  as  the  CRT 
monitors,  display  drivers,  printers,  console  devices, 
interface  logic  backup  devices,  communications 
equipment,  video  hard  copies,  etc. 
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RTU  Maintenance  - The  instructions  on  how  to  maintain, 
troubleshoot,  repair, (at  a module /card  level)  and 
adjust  the  remote  equipment  using  their  associated 
test  sets 

° CPU  Software  - The  instructions  on  how  to  efficiently 
use  and  program  the  mainframe  supplied  software,, 
utilized  and  supplied  with  the  system,  including  the 
real-time  operating  system,  assembly  languages,  pro- 
gramming, instruction  set,  loaders,  assemblers, 
compilers,  macro  language  and  usage,  higher  order 
languages,  machine  functions,  and  control  machine 
services,  system  build,  program  debugging,  etc. 

° System  Software  - The  instruction^  on  how  to  efficient- 
ly use  and  maintain  the  system  software  supplied  as 
part  of  the  system  by  the  Vendor,  including 
communications  software,  report  generation,  display 
generation,  data  base  and  display  generation  and 
change,  failure  detection  software,  etc. 

° Application  Program  Software  - The  instructions  on  how 
to  efficiently  use  and  maintain  the  applications 
programs  supplied  as  part  of  the  system  by  the 
Supplier 

6 . Maintenance  Plan  and  Spare  Parts 

The  Vendor  should  submit  a maintenance  plan  and  list  for 
spare  provisioning.  The  plan  should  develop  the  philosophy, 
and  detail  the  procedure  for  transfer  of  maintenance 
responsibility  from  the  Vendor  to  the  Borrower.  This 
should  be  coordinated  with  the  training  plan.  It  is  the 
desire,  that  within  a reasonable  period  of  time, the 
Borrower  become  self-sufficient  in  all  aspects  of  main- 
tenance . 

The  initial  spare  parts  list  should  show  type  and  quantity 
of  all  spares  expected  for  use  in  the  system, and  the 
expected  Attrition  rate  of  each  part,  module,  etc., 
supplied, to  support  normal  operation  over  a one-year 
period. 

7 • Program  Documentation 

As  a standard  procedure,  schedule  updating  and  status 
reports  describing  activities,  accomplishments,  and  problems 
should  be  submitted  monthly,  until  the  system  is  finally 
accepted. 
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Plans  should  be  developed  for  the  following  efforts: 

0 Training 

0 Maintenance 

° Test  and  acceptance 

° System  program  management 

8 . Project  Coordination  and  Management 

A program  management  plan  detailing  how  the  project  is  to 
be  scheduled,  coordinated,  and  managed  should  be  developed. 
The  plan  should,  as  a minimum,  cover  the  following 
project  phases: 

° System  design 

0 Quality  assurance 

° Procurement 

° Software  development 

° Subsystem  hardware /software  test 

0 Factory  system  build  and  acceptance  test 

° Installation 

° Integration  and  activation 

° System  demonstration,  on-line  evaluation,  and  final 
acceptance 

° Program  status  and  reporting 

The  plan  should  detail  the  available  personnel  resources 
and  management  by  name,  including  the  project  manager,  and 
his  specific  responsibilities.  Qualifications  of  key 
individuals  should  be  included, along  with  their  present 
assignment  to  this  project. 

The  plan  should  detail  how  a realistic  schedule  is  to  be 
developed  and  managed;  how  work  is  to  be  defined, 
scheduled,  and  controlled;  how  software  design,  coding, 
integration,  and  test  are  to  be  controlled;  how  design 
reviews  are  to  be  accomplished,  how  changes  are  controlled. 
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how  contract  data  items  are  scheduled,  produced  and  deliv- 
ered ; how  subcontractors  and  suppliers  are  to  be  managed; 
how  quality  assurance  is  to  be  enforced,  and  how  liaison 
and  reporting  with  the  Borrower  is  to  be  accomplished. 

9 • Document  Changes 

Documents  should  be  identified  by  a document  number. 
Changes  and  revisions  should  be  appropriately  indicated  on 
the  face  of  the  drawing  by  a change  sheet  in  the  front  of 
the  document.  The  information  on  the  drawing  or  change 
sheet  identifies  the  change  number,  date,  and  subject  of 
change,  location  of  change,  requesting  and/or  approving 
document,  and  authorizing  person.  Actual  revisions  to 
drawings  or  document  pages  may  be  marked  or  otherwise 
identified  for  ease  of  location. 

The  yendor  must  be  responsible  for  maintaining  change 
control  over  the  delivered  document  set  for  a period 
which  extends  through  the  warranty  time.  This  includes  all 
corrections  due  to  hardware  changes,  and  document  inaccur- 
acies or  deficiencies  determined  during  usage.  Changes 
to  published  documents  should  be  made  by  substitution  of 
corrected  pages  or  drawings  for  the  incorrect  pages  or 
drawings.  Changed  pages  should  be  suitably  marked  for  a 
date  of  change,  and  areas  on  the  page  that  were  changed. 
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H.  General  Design  Criteria 


This  section  describes  goals  which  may  be  used  as  system 
design  criteria.  The  system  should  meet  all  objectives, 
consistent  with  some  degree  of  compromise  to  optimize  cost. 
Currently  existing  circumstances , operating  philosophy  and 
the  growth  characteristics  at  most  Borrower  facilities  should 
form  the  requirements  and  guide  engineering  decisions. 

1 . High  Availability 

Considering  the  importance  of  supervisory,  dispatching, 
and  control  activities  in  terms  of  the  value  of  daily 
production,  loss  of  control,  in  whole  or  in  part, cannot 
be  tolerated  for  more  than  extremely  short  periods.  Typi- 
cal systems  can  be  expected  to  achieve  the  industry 
standard  of  99*8%  availability  for  critical  functions. 
Higher  availability  may  not  be  possible  to  achieve  except 
at  an  unreasonable  expense.  The  figure  of  99-8%  is, 
however,  unrealistically  high  for  single-  computer  con- 
figurations. A 99-8%  availability  will  result  in  a 
cumulative  failure  rate  of  17.6  hours  per  year,  well 
within  the  capabilities  of  currently  available  dual 
computer  systems.  Lesser  availability  figures  would  be 
acceptable  for  equipment  elements  other  than  those 
directly  concerned  with  control  and  data  acquisition 
functions. 

2 . Redundancy  and  Backup  Goals 

The  proposed  ECS  or  SCADA  system  should  be  designed  so 
that  a single  component  failure  anywhere  in  the  system 
will  not  result  in  the  loss  of  a critical  function.  Where 
feasible,  multiple  component  failures  should  be  pro- 
tected against , particularly  where  devices  are  more  sus- 
ceptible to  outages  and/or  have  potentially  long  repair 
times.  If  a spare  component  is  required  to  maintain  high 
system  availability,  and  it  can  be  useful  in  supporting 
a noncritical  function,  it  should  be  incorporated  as  an 
on-line  component.  Of  all  functions,  data  acquisition, 
supervisory  control, and  automatic  generation  control, are 
considered  of  prime  importance.  Other  critical  ECS 
functions  should  be  defined  as  system  design  proceeds. 

3.  Reliability  and  Security 

The  proposed  computer  system  should  have  strong  reliabil- 
ity and  security  characteristics.  Reliability  is  defined 
as  the  readiness  of  the  system  to  operate  whenever 
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circumstances  and  a dispatcher  require  it  to  operate. 
Security  is  defined  as  a characteristic  which  prevents 
the  system  from  operating  except  at  the  expressed  and 
verified  demand  of  a dispatcher  or  the  built-in  logical 
functions  of  its  programs.  Both  characteristics  must  be 
incorporated  into  the  hardware  and  software  of  the 
system  during  design,  specification, and  implementation. 

1+.  State-of-the-Art  Design 

Although  it  may  be  possible  to  procure  a reliable  system 
which  satisfies  current  system  functions  in  a tradition- 
al manner,  the  proposed  system  should  utilize,  wherever 
practicable,  proven  state-of-the-art  techniques.  These 
techniques  are  usually  developed  to  solve  shortcomings  in 
existing  systems,  or  to  satisfy  expanded  needs  not  ade- 
quately satisfied  by  existing  equipment.  Many  of  these 
techniques  are  involved  in  man/machine  interfaces.  Others 
improve  the  reliability  and  security  of  the  hardware  of 
computer-based  systems.  State-of-the-art  approaches  to 
system  design  should  not  incorporate  difficult  mainten- 
ance problems.  State-of-the-art  approaches  should  not 
involve  developmental  work  on  unproven  control  tech- 
niques, or  the  purchase  of  an  experimental  system. 

Rather,  they  should  improve  monitoring  and  control  capa- 
bilities of  the  system  and  forestall  premature  obsole- 
scence . 

5 • Man/Machine  Interface 

The  new  control  system  is  primarily  a dispatcher  tool. 

New  techniques  which  improve  the  efficiency,  ease,  and 
speed  by  which  equipment  may  be  monitored,  dangerous 
conditions  pinpointed,  control  actions  forwarded  to  re- 
mote equipment,  and  monotonous  activity  relieved,  must 
be  seriously  considered.  The  dispatcher  must  be  given 
tools  which  allow  him  to  perform  his  increasingly  criti- 
cal tasks  satisfactorily. 

6 . Conservation  of  Manpower 

Operational  use  of  manpower  is  a direct  function  of  system 
design.  The  new  system  should  require  a minimum  number 
of  personnel  for  daily  operations,  updating,  and  main- 
tenance. In  evaluating  system  concepts,  the  effective 
use  of  dispatcher  manpower  is  of  prime  importance. 
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7 . Minimum  Capital  Investment 


In  any  uncertain  State-of-Money  market,  the  goal  of 
minimum  capital  investment  is  of  great  importance.  This 
goal  must  be  considered  an  important,  but  not  the  only 
element  of  the  total  cost  of  the  system  over  its  useful 
life.  Low  initial  capital  cost  may,  for  example,  be 
negated  by  high  operating  costs,  maintenance  costs,  and 
the  costs  for  expansion  beyond  the  portion  of  the  system 
initially  purchased.  The  main  cost  of  a large  control 
system  lies  in  the  cost  of  its  software  and  remote 
terminal  units,  and  their  installation  and  servicing, 
rather  than  the  cost  of  the  master  equipment. 

8.  Economic  Operating  Costs 

This  goal  must  be  coupled  with  minimum  manpower,  main- 
tenance, communication,  and  capital  costs.  The  control 
system  should  be  easy  to  maintain  and  have  a minimum 
incremental  relationship  between  RTUs  and  added  opera- 
ting maintenance  personnel.  It  must  be  accepted,  however, 
that  every  added  piece  of  equipment  will  increase  opera- 
ting costs  in  the  form  of  communication  requirements, 
maintenance,  and  amortization/depreciation  expenses,  even 
though  direct  manpower  costs  may  not  be  affected. 

9-  Economic  Communication  Costs 


While  the  tradeoffs  between  manpower  and  communication 
is  generally  in  favor  of  the  latter,  there  is  still 
ample  opportunity  to  design  a system  which  minimizes 
communication  demands.  These  costs  are  particularly 
heavy  if  multiple  separate  communication  paths  serve  the 
same  location  for  purposes  of  back  up  or  redundancy. 
Party  lining  of  selected  RTUs,  without  loss  of  effective 
control  practices,  is  an  acceptable  operation,  since 
considerable  savings  in  operation  can  be  a result. 

10 . Maint ainab ility 

The  control  system  should  be  designed  for  ease  of  main- 
tenance, using  a minimum  number  of  personnel.  Shelf 
spares  for  vulnerable  items  of  equipment  should  be  held 
at  a central  location.  Stockpiling  of  expensive  major 
items  of  equipment  should  be  avoided,  and  are  not  nec- 
essary to  attain  acceptable  standards  of  availability. 
Training  of  personnel  should  not  be  wholly  dependent 
on  the  equipment  manufacturers,  nor  should  the  education 
level  and  training  demanded  of  maintenance  personnel  be 
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excessively  high.  Equipment  should  be  easily  accessed, not 
sensitive  to  normal  ambient  temperature  changes,  and  not 
dependent  on  an  uninterrupted  air  conditioned  environ- 
ment for  proper  operation.  Diagnostics  for  all  system 
elements  should  be  supplied  by  the  manufacturer  and 
available  to  organizational  maintenance  personnel. 

11.  Expandab ility 

Hardware  and  software  should  be  capable  of  easy  expansion, 
with  minimum  downtime, to  accomodate  anticipated  growth  in 
any  system.  During  the  life  span  of  the  system,  the 
number  of  lines  may  be  increased,  new  generating  units 
added,  and  the  software  asked  to  perform  sophisticated 
analytical  tasks.  The  system  must  be  expected  to  grow 
with  increases  in  the  size  or  number  of  auxiliary 
memories,  and  the  addition  of  main  memory  modules  and 
I/O  channels.  Additional  peripherals  for  logging,  plotting, 
display,  or  data  collection, may  be  added  during  the  life 
of  the  system.  The  selected  system  should  be  capable  of 
absorbing  normal  computer  system  growth.  Capability  for 
expansion  should  be  purchased,  though  it  may  not  be 
fully  activated  for  a number  of  years  to  come.  Expansion 
capabilities  must  be  included  in  the  specification  to  pre- 
vent costly  under,  or  over-design  by  a manufacturer. 

12 . Life  Span 

The  new  system  should  have  a minim-urn  life  span  of  12 
years.  Based  on  the  experience  of  other  utilities,  12 
years  is  a reasonable  goal.  In  earlier  systems  where 
initial  functions  were  firm,  functional  additions  mini- 
mal, and  the  electrical  system  relatively  static,  life 
spans  longer  than  12  years  were  achieved.  Normally,  dig- 
ital systems  will  deteriorate  with  age , particularly  all 
electro-mechanical  peripherals.  Availability  will  de- 
crease with  time,  and  replacement  or  compatible  equip- 
ment will  become  difficult  to  obtain.  The  system  design 
should  allow  for  the  possibility  of  expansion  to  include 
all  anticipated  future  functions.  RTUs  can  be  expected  to 
have  a life  span  well  in  excess  of  12  years.  Master 
station  life  span  will  depend  on  the  existence  of  spare 
parts,  the  quality  of  maintenance  performed,  and  the 
commitment  of  manufacturers  to  continue  support  for 
their  older  products. 
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Technological  obsolescence  will  also  have  influence  on 
the  effective  life  span  of  a system.  The.  continuous 
progress  of  the  computer  industry  towards  more  powerful 
and  less  costly  equipment  has  allowed  manufacturers  to 
offer  new  applications  for  systems  in  each  evolutionary 
cycle.  As  the  control  system  passes  through  mid-life, 
newer  systems  with  added  and  improved  functions  will  add 
to  the  forces  propelling  the  system  towards  end-of-life. 

A continuous  evaluation  must  be  performed  at  this  stage 
of  system  life,  balancing  the  worth  of  continued  use  and 
maintenance  of  the  current  system  against  the  cost  of 
replacement . 

13 • Personnel  Safety  Design 

Control  systems  design  should  incorporate  the  following 
system  features: 

° All  operating  controls  should  be  kept  at  ground 
potential. 

° Wherever  operating  voltages  in  the  equipment  exceed 
100  volts,  the  equipment  should  be  shielded  from 
accidental  contact  and  should  be  protected 
accordingly . 

° Equipment  should  have  no  sharp  corners  or  edges. 

All  edges  shall  be  rounded  to  prevent  injury  and 
accident . 

° Equipment  should  be  designed  in  accordance  with  the 
Underwriters  Laboratory  specifications  for  fire 
resistance,  and  in  accordance  with  state  and  local 
safety  codes. 
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IV . SYSTEM  IMPLEMENTATION 


A.  General 


This  section  reviews  implementation  plans  from  the  problem 
definition  phase  through  operational  checkout.  The  im- 
plementation passes  through  three  broad  phases: 

° Information  gathering  - begins  with  a problem  in  sys- 
tem control  and  ends  with  alternative  solutions 

0 Learning  - starts  with  selecting  one  of  the  alternatives 
and  ends  with  the  installation  of  the  control  system 

° Execution  - this  final  phase  starts  with  the  date  the 
system  is  turned  over  for  operation,  and  ends  when 
management  decides  to  replace  the  system 

An  energy  control  center  design  passes  through  at  least  seven 
distinct  phases  in  its  implementation  process.  The  phases  are: 

° Problem  definition 

0 Preparation  of  functional  specifications 
° Evaluation  of  Bids  and  Project  Schedule 
0 Design  approval  and  Responsibilities 
0 Acceptance  testing 
° Installation 
° Operational  checkout 

Each  phase  requires  close  coordination  between  management  and 
engineering  in  order  to  effect  system  implementation  liaison 
with  the  Vendor  during  the  design,  test,  installation,  and 
operational  checkout  of  the  system. 

Once  it  is  decided  that  a problem  exists,  and  prior  to  the 
start  of  the  definition  phase,  it  is  necessary  to  establish  a 
team  for  investigating  and  assessing  the  potential  of  imple- 
menting a control  system.  This  begins  with  the  selection  of  a 
project  manager.  The  project  manager  should  be  from  the  user 
organization,  preferably  from  the  operations  group. 

The  composition  of  the  study  team  depends  upon  the  resources 
of  the  electric  system  Borrower.  Ideally,  the  study  team 
should  be  comprised  of  an  individual  from  each  of  the  follow- 
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ing  organizations,  as  applicable  to  the  particular  Borrower 
structure  (i.e.  Generation  and  Transmission  or  Distribution 
System  Borrower): 

° System  operations 

° Transmission  engineering 

0 Distribution  engineering 

° Dispatch 

° Test  department 

B.  Problem  Definition 


Most  Borrowers  control  centers  are  an  evolution  of  some  form 
of  manual  or  semi-automatic  dispatch  operation,  put  together 
by  operating  personnel  responding  to  the  day-to-day  operations 
and  crises  of  their  jobs.  In  many  instances,  it  is  neither 
possible  nor  prudent,  to  launch  into  a study  without  either 
consulting,  or  learning  how  the  dispatcher  functions.  Further- 
more, it  is  unwise  to  procure  a system  which  is  less  than 
optimal  in  either  assisting  the  dispatcher,  or  in  augmenting 
the  dispatch  function.  By  the  same  token,  no  system  design  is 
totally  predicated  on  the  desires  of  the  dispatcher.  Rather, 
this  most  important  phase  is  approached  with  a set  of  objectives 
which  are  consistent  with  the  mission  of  the  Borrower,  that  is, 
as  he  may  function  as  a G&T  or  a distribution  facility. 

The  procedures  of  the  problem  definition  phase  as  simply 
stated  are: 

0 Review  present  operating  methods  and  systems 

° Develop  basic  functions  to  be  performed  by  the  system 

° Develop  several  alternative  solutions  and: 

make  technical  and  operational  comparisons 
make  economic  comparisons 
select  a preferred  concept 

° Establish  detailed  functional  requirements  for  a pre- 
ferred concept 

° Establish  building  and  related  facility  and  support 
requirements 

° Establish  a project  implementation  plan 
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Borrowers  are  finding  that  the  use  of  outside  engineering  ser- 
vices to  assist  in  performing  requirements  studies  has  several 
significant  benefits.  The  consultant  will  have  performed  sim- 
ilar studies  for  other  utilities,  and  will  be  very  familiar 
with  current  state-of-the-art  practices,  in  defining  new  con- 
trol system  requirements.  He  will  apply  this  experience  to 
the  project  and  can  substantially  improve  the  prospects  of 
achieving  the  planning  objectives.  It  is  expected  that  the 
cost  of  such  services  will  be  offset  by  savings  in  the  overall 
system  life-cycle  costs. 

Once  the  problem  has  been  identified,  with  the  possible  in- 
creased costs  of  operation  due  to  existing  methods  known, 
management  will  need  to  know  the  magnitude  of  resources  re- 
quired, and  the  potential  benefits  and  risks  involved  if 
the  project  does  not  go  as  planned. 

C.  Preparation  of  Functional  Specification  and  Contract  Document 

The  specification  for  the  control  system,  while  presenting 
firm  functional  requirements,  should  be  as  nonrestrict ive  as 
possible  in  describing  actual  implementation.  Utilization  of 
a Vendor's  standard  existing  hardware  and  software,  where  this 
hardware  and  software  satisfies  functional  requirements,  is 
clearly  to  the  Borrower's  advantage.  Where  designs  are  pre- 
sented to  the  Vendor,  they  should  be  presented  as  suggestive 
of  intent  rather  than  absolute  requirements. 

The  specification  for  the  control  system  should  be  written  with 
the  difficult  task  of  evaluation  in  mind.  Simple  timing 
studies,  algorithms,  and  test  cases  should  be  provided.  A 
questionnaire  embodying  important  specific  questions  concern- 
ing the  characteristics  of  the  proposed  system  will  aid  the 
project  staff  in  evaluating  proposals,  and  provide  an  index 
to  the  voluminous  material  normally  associated  with  proposals 
of  this  type. 

Many  companies  are  presently  producing  SCADA/EMS  Systems  and 
are  potential  suppliers  of  the  control  system.  Careful  pre- 
selection of  Bidders  is  necessary  to  optimize  the  quality  and 
effort  of  the  proposal  evaluation  by  the  project  team.  Ex- 
perience and  capabilities  vary  among  Vendors  and  individual 
evaluations  are  required  to  establish  acceptable  candidates. 

A Vendor's  experience  with  projects  of  comparable  scope  and 
complexity  will  impact  the  implementation  period,  possibly 
extending  the  time  from  contract  award  to  final  system  accept- 
ance. The  supplier's  initial  capability  plus  his  interest  and 
ability  in  servicing  the  project  throughout  its  useful  life 
are  considered  of  primary  importance. 
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The  project  team  assigned  the  task  of  evaluation  of  the  con- 
trol system  offerings  should  embody  their  findings  in  a for- 
mal evaluation  report.  This  report  will  summarize,  for  their 
own  and  management’s  use,  a comparison  of  the  systems 
offered  by  the  Vendors.  The  pricing  instructions  of  the 
specification  will  aid  in  the  preparation  of  a tabulation 
displaying  the  cost  of  individual  elements  of  the  system. 
Reasonable  costs  will  also  be  assigned  to  such  imponderables 
as  future  service  risk,  man/machine  convenience,  programming 
ease,  experience  of  the  Vendor  in  electric  utility  appli- 
cations, developmental  risks  and  others.  The  evaluation 
report  will  be  based  on  a close  reading  of  the  proposals, 
formal  presentations  by  the  Vendors,  the  Vendors'  replies  to 
questionnaires,  and,  in  some  cases,  direct  visits  to  plants 
and  existing  installations  where  the  equipment  proposed  is  in 
daily  use . 

Following  an  authorization  to  proceed,  the  successful  Vendor 
should  be  prepared  to  participate  in  a joint  effort  with  the 
project  staff  to  produce  final  contract  documentation  based 
on  the  specification.  This  document  will  consist  of  the 
specification  as  modified  by  a table  of  conformance.  This 
table  of  conformance  shall  address  each  paragraph  of  the 
specification  and  shall  state  the  extent  to  which  the  delivered 
system  will  deviate  from  the  specified  requirements.  The 
Vendor's  proposed  implementation  and  technical  agreements 
reached  during  prebid  and  evaluation  phases  shall  thereby  be- 
come a part  of  the  technical  contract.  The  document  should 
be  used  as  a guide  throughout  the  project,  and  be  binding  on 
both  parties. 

D . Evaluation  of  Bids  and  Project  Schedule 
1.  Bid  Evaluation 


The  bid  evaluation  is  one  of  the  most  important,  if  not 
the  most  difficult,  phase  of  a project.  It  requires  not 
only  the  skills  of  both  hardware  and  software  engineers, 
but  also  the  ability  to  assimilate  and  integrate  all 
facets  of  the  Vendor's  proposal.  If  the  Borrower's  engi- 
neering has  participated  to  the  fullest  extent  up  to  this 
point,  much  of  the  burden  may  be  offset.  However,  this  is 
a point  in  the  project  where  the  services  of  a qualified 
consulting  firm  should  be  considered. 

The  following  are  some  considerations  and  methods  that 
may  be  used  for  bid  evaluation: 

° Rank  the  items  of  the  system  functional  specifi- 
cation as  MUSTS  or  WANTS,  and  determine  how  each 
proposal  satisfies  both  categories 
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° Purchase  an  operating  system  supplied  by  the  Com- 
puter manufacturer 

0 Establish  past  performance  of  the  Vendor  on  Energy 
Control  Center  projects 

° Determine  the  number  of  years  a Vendor  is  capable 
of  supporting  his  product 

° Request  an  itemized  quotation  for  elements  of 
hardware  and  software  — this  is  particularly  im- 
portant if  you  are  going  to  normalize  various 
proposals  to  a standard  offering. 

° Determine  the  limitations  of  the  proposed  system 
provisions  for  future  hardware  expansions 

° Evaluate  what  trade-offs  can  be  realized  between 
memory  requirements  and  higher  level  language  for 
system  programming 

° Determine  if  your  consultant's  assistance  in 
evaluation  expertise  is  competent  in  all  the  re- 
quired areas 

A detailed  report  of  the  bid  evaluation,  with  recommenda- 
tions, should  be  prepared  for  both  Borrower  management 
and  REA  review.  The  emphasis  should  be  on  how  the  selected 
proposal  best  meets  the  objectives  of  the  planned  control 
center  design,  and  why  the  other  alternatives  do  not. 

2.  Project  Schedule 

A typical  Project  Schedule  for  the  design,  implementation, 
and  testing  of  the  ECS  is  discussed  in  this  section.  The 
estimates  used  in  this  schedule  are  based  on  average 
task  times  for  illustrative  purposes  only,  and  serve  to 
identify,  chronologically,  the  sequence  of  events  in  the 
overall  project  implementation. 

Phase  Schedules 


The  estimates  contained  in  this  section  are  presented  in 
terms  of  average  calendar  weeks  to  complete.  Phases  are 
well  defined  groups  of  tasks,  bound  by  time,  culminating 
in  milestone  documents. 

° Phase  1 - This  phase  commences  with  the  submission 
of  a report  which  includes  time  for  the  review  of 
the  report,  design  of  an  acceptable  system  and 
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its  specification,  and  the  review  of  the  specifi- 
cation. Approximately  26  calendar  weeks  have  been 
allocated  for  this  phase 

° Phase  2 - Allow  8 weeks  for  bid  preparation  by  the 
Vendors.  During  this  period,  the  project  staff  will 
continue  expanding  system  design  requirements, 
and  gathering  the  detailed  system  data  that  will  be 
required  by  the  successful  bidder.  During  Phase  2, 
proposals  will  be  carefully  evaluated  and  the 
findings  and  recommendations  of  the  project  staff 
summarized  in  a final  evaluation  report.  Following 
delivery  of  a letter  of  intent  to  the  selected 
Vendor,  a final  contract  document  will  be  signed 
based  on  the  specification,  the  Vendor's  proposal 
and  any  agreements  reached  during  the  evaluation  and 
presentation  period.  A total  of  25  calendar  weeks 
are  allocated  to  Phase  2 

° Phase  3 - Encompasses  all  activities  between  the 
time  the  contract  is  signed  and  the  time  the  system 
is  shipped  from  the  Vendor's  manufacturing  facility. 
The  activities  are  those  normally  associated  with 
the  production  of  a control  system  including 
computer  procurement,  hardware  manufacture  and  test, 
software  design  code  test,  system  integration,  and 
the  factory  acceptance  test.  This  phase  is  esti- 
mated to  require  73  calendar  weeks 

° Phase  h - Activities  are  performed  at  the  Borrower's 
facilities.  During  the  ending  weeks  of  Phase  3, 
the  control  room  and  equipment  rooms  have  been 
prepared  to  receive  the  consoles  and  equipment. 
Installation  (4  weeks)  is  followed  by  start  up  and 
check  out  (k  weeks),  and  a preliminary  field 
acceptance  test  similar  to  the  factory  test.  Final 
acceptance  of  the  system  follows  successful  running 
of  a 1000  hour  availability  test.  The  test  can  be 
expected  to  require  12  weeks  to  complete 

° Phase  5 - Identifies,  and  chronologically  orients 
the  activities  that  must  be  accomplished  to  ensure 
the  availability  of  the  ECS  building  and  communi- 
cation facilities  when  the  computer  system  is 
received 

The  time  required  to  achieve  full  system  operation  is 
approximately  133  weeks.  A 1000  hour  acceptance  test 
will  require  an  additional  12  weeks. 
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E.  Design  Approval  and  Responsibilities 

1.  Design  Review  and  Approval 

Preliminary  final  design  reviews  approvals  should  be  held 
by  the  Supplier  at  his  facility  to  conserve  costs.  The 
Borrower  should  be  prepared  to  provide  acceptance  approval 
at  each  of  these  reviews.  The  preliminary  design  review 
should  be  held  early  in  the  program,  before  any  major  de- 
sign effort  has  started  and  later  in  the  program  before 
any  major  fabrication  or  coding  has  started.  These  design 
reviews  are  used  to  assure  that  maximum  compliance  to  the 
functional  requirements  is  being  accomplished. 

2.  Vendor  and  Borrower  Responsibilities 

The  Vendor  and  Borrower  both  share  in  the  responsibility 
of  designing,  fabricating,  integrating,  testing,  and 
demonstrating  the  hardware  and  software  comprising  the 
ECS.  Vendor  and  Borrower  responsibilities  are  defined 
in  the  following. 

a.  System  Design,  Fabrication,  Tests,  and  Delivery 

It  is  the  Vendor's  responsibility  to  provide  for  the 
system's  hardware  and  software  design,  manufacturing, 
preparation,  assembly  integration,  and  test.  The 
Vendor  shall  be  responsible  for  functional  integrity 
of  all  the  internal  and  external  system  interfaces. 
Where  required  the  Vendor  shall  make  on-site  visits 
to  determine  interface  requirements. 

The  Borrower  should  provide  all  necessary  updated 
power  system  information. 

The  Vendor  should  be  fully  responsible  for  the 
packing  and  safe  shipment  of  all  system  hardware . 

b . Documentation 

The  Vendor  shall  provide  all  documentation  in  a 
timely  and  orderly  manner.  It  will  be  the  responsi- 
bility of  the  Borrower  to  conduct  appropriate  re- 
views of  documents  requiring  acceptance  approvals. 

c.  Training 

The  Vendor  should  describe  a training  plan  as  part  of 
this  proposal  and  furnish  all  training  courses  unique 
to  his  equipment.  The  Borrower  should  coordinate  with 


IV-7 


the  Vendor  in  making  personnel  available  to  attend 
these  courses. 

d . Quality  Assurance 

The  Vendor  is  to  provide  a complete  description  of 
his  Quality  Assurance  Plan,  and  he  shall  be  respon- 
sible for  conduction  Quality  Assurance  Inspections, 
tests,  and  reporting  in  accordance  with  his  Quality 
Assurance  Plan. 

e . System  Activation 

The  Vendor  should  furnish  a system  activation  plan  and 
procedure.  The  Borrower  and  Vendor  must  work  together 
in  the  accomplishment  of  a secure  and  smooth  system 
activation  and  cutover. 

f . Performance  Warranty 

The  Vendor  should  provide  at  least  a one  (l)  year 
performance  warranty  on  the  total  ECS  beginning  at 
the  time  of  final  acceptance.  The  warranty  should 
cover  the  repair,  rework,  replacement  of  any  hardware 
or  software  items  that  do  not  meet  the  performance 
and  availability  requirements  of  the  specification. 

This  warranty  should  cover  all  parts,  materials, 
labor,  travel,  and  per  diem,  in  effecting  any  and  all 
corrective  actions  by  the  Vendor. 

g . Program  Management 

The  Vendor  should  provide  a staff  of  qualified  per- 
sonnel to  manage  the  ECS  project.  The  Vendor's 
management  team  should  manage,  control  and  coordinate 
the  development  of  the  system,  integration,  testing, 
delivery,  and  system  demonstration  and  final  acceptance 
The  Vendor  should  assign  a Project  Manager,  acceptable 
to  the  Borrower,  to  serve  as  a focal  point  for  overall 
project  management.  In  like  manner,  the  Borrower 
should  assign  an  ECS  Project  Manager.  All  formal 
communications  between  Borrower  and  Vendor  should 
be  exchanged  through  the  Project  Managers  or  their 
designated  alternates. 

The  Vendor  should  provide  an  organization  chart  show- 
ing the  organizational  responsibilities  and  names  of 
key  personnel  intended  to  be  assigned  to  the  program. 
Resumes  of  key  personnel  should  be  provided. 
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F.  Acceptance  and  Testing 


All  materials  and  hardware  to  he  furnished  and  all  work  to  he 
performed  under  the  ECS  specification  should  he  subject  to 
inspection  and  tests.  All  shipments  should  be  deferred  until 
inspections  and  tests  have  been  completed  and  the  Borrower 
issues  authorization  for  shipment.  Acceptance  of  hardware, 
or  the  waiving  of  inspection  and  tests,  should  not  relieve 
the  Vendor  of  the  responsibility  for  furnishing  a system  that 
meets  the  specification.  The  Borrower  should  reserve  the 
right  to  request  additional  tests  on  any  work  determined  to 
be  not  in  accordance  with  the  specification.  Deletions  and 
changes  to  the  specification  during  implementation  phases  of 
the  project  should  be  properly  documented  and  approved. 

1.  Inspection 

The  Borrower's  representatives  should  have  free  entry 
into  the  shops  of  the  Vendor  while  fabrication  and  test- 
ing is  in  progress,  or  into  any  mill,  shop  or  factory 
where  the  hardware  or  software  is  being  produced.  The 
Vendor  should  allow  the  Borrower's  representatives,  free 
of  cost,  all  reasonable  facilities  necessary  to  establish 
that  material  fabrication  is  in  accordance  with  the 
specifications.  Inspection  results  should  not  relieve 
the  Vendor's  responsibility  of  building  a system  which 
conforms  to  the  specification,  nor  invalidate  any 
Borrower  claim  resulting  from  defective  or  unsatisfactory 
material  and  hardware.  Inspection  visits  by  the  Borrower's 
representatives  should  be  performed  on  a regular  basis  to 
ascertain  the  accuracy  of  submitted  reports  and  schedules. 

2.  Test  Plans 


The  Vendor  should  submit  test  plans  for  all  factory  and 
field  acceptance  tests.  Test  plans  should  be  submitted 
to,  and  approved  by,  the  Borrower  prior  to  the  com- 
mencement of  each  test.  Hardware  test  plans  should  ex- 
plain the  purpose  of  the  tests,  define  test  inputs, 
specify  test  procedures,  and  define  outputs  to  be 
achieved.  Software  test  plans  should  include  a summary 
of  the  methods,  a list  of  test  cases,  and  expected  results. 
The  Borrower  should  be  given  at  least  three  weeks  after 
receipt  of  test  plans  for  their  approval  process.  All 
test  plans  should  include  periods  for  unspecified  ex- 
ercising of  the  hardware  and  software  by  the  Borrower's 
representatives.  Factory  tests  and  availability  tests 
should  not  proceed  without  the  prior  delivery  of  hard- 
ware and  software  documentation. 
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3 .  Test  Reports 


The  Vendor  should  transmit,  to  the  Borrower’s,  rep- 
resentative all  factory  and  field  acceptance  tests.  Each 
report  should  include  the  purpose  and  method  of  the  tests, 
the  persons  witnessing  the  test,  and  a description  of 
any  deviations  from  the  procedures  described  in  the 
previously  approved  test  plan.  Each  report  should  in- 
clude test  data  that  is  compared  with  expected  results. 

The  data  furnished  should  demonstrate  conclusively  that 
the  element  performed  within  specification  during  all 
of  the  tests.  The  observations  of  the  Borrower's  rep- 
resentatives present  at  factory  and/or  field  acceptance 
tests  should  be  included  in  the  test  report. 

4 . Unit  Design  Performance  Tests 

Each  major  unit  or  subsystem  should  be  tested  when 
fabrication  and/or  integration  has  been  completed.  All 
tests  should  be  identified  in  the  system  schedule  at  the 
outset  of  the  project.  The  Vendor  should  verify  the 
schedule  of  individual  tests  in  sufficient  time  for  the 
Borrower  to  schedule  manpower  and  finalize  travel  plans. 

In  instances  of  insufficient  notice  or  change  of  schedule 
beyond  the  control  of  the  Borrower,  the  right  should  be 
reserved  to  reschedule  test  demonstrations  and,  if 
warranted,  to  consolidate  tests. 

5 . Routine  Quality  Control  Tests 

All  components  and  assemblies  comprising  a subsystem 
should  be  given  routine  factory  tests.  These  tests 
should  be  documented  in  accordance  with  pr actives 
delineated  in  the  Vendor's  quality  control  and  assurance 
programs  described  in  his  proposal.  The  Borrower  should 
have  access  to  these  reports  on  request.  No  test  plans 
are  required  for  routine  factory  tests.  All  purchased  or 
manufactured  components  should  be  quality  inspected  and 
tested  subject  to  the  Borrower's  approval. 

6 . Factory  Performance  Tests 

The  Borrower's  project  team  should  witness  a fully  in- 
tegrated factory  test  at  the  Vendor's  factory.  The 
purpose  of  this  test  is  to  exercise  system  hardware  and 
software  under  simulated  conditions  prior  to  shipment. 

If  tests  are  unsatisfactory,  shipment  authorization 
should  be  withheld  and  factory  tests  rerun.  Corrective 
measures  should  be  expeditiously  completed  when  equipment 
and  technical  personnel  are  available.  Only  extra- 
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ordinary  circumstances  warrant  shipment  authorization 
prior  to  full  compliance  with  the  test  objectives.  The 
Vendor  should  be  required  to  complete  corrections  at  no 
cost  to  the  Borrower  before  shipment.  The  successful 
completion  of  factory  tests  will  not  constitute  final 
accemtance  of  the  system  or  any  portion  thereof. 

7 . Preliminary  Field  Acceptance  Test 

Following  installation  of  the  sytem,  all  hardware  should 
be  aligned  and  adjusted,  and  all  test  readings  recorded 
in  accordance  with  the  Vendor's  recommended  alignment  and 
test  procedure.  The  Vendor  should  include  in  his  test 
reports  a list  of  all  hardware  or  components  replaced  or 
interchanged  after  completion  of  the  factory  tests,  and 
prior  to  the  commencement  of  the  preliminary  field 
acceptance  test.  After  initial  alignment  and  adjustment 
of  the  hardware,  the  Vendor  should  repeat  a brief  form 
of  the  -unit  design  performance  tests  which  were  con- 
ducted at  the  factory.  A performance  test  should  also 
be  conducted  to  verivy  that  correct  data  interchange  is 
secured  over  all  interfaces  and  that  the  hardware  and 
software  is  fully  operational. 

After  these  interfaces  are  verified,  the  factory  per- 
formance tests  should  be  repeated  at  the  final  system 
locations.  Allowances  should  be  made  for  the  absence  of 
simulation  or  test  gear  not  available  outside  the  Vendor's 
factory  (e  .g ./ equipment  required  to  demonstrate  satis- 
faction of  ambient  temperature  requirements).  All 
hardware  and  software  will  be  demonstrated  to  be  oper- 
ational during  the  preliminary  field  acceptance  test. 

The  exact  procedures,  commencement  time  and  date  of 
the  preliminary  field  acceptance  test  will  be  described 
in  advance  and  by  mutual  agreement  between  the  Borrower 
and  the  Vendor. 

8.  1000-Hour  Availability  Test 

After  the  preliminary  field  acceptance  test  has  proven 
the  system  to  be  fully  operational  with  a full  complement 
of  RTUs,  a 1000-hour  availability  test  should  be  con- 
ducted, commencing  at  a mutually  agreed  time.  This 
should  be  considered  the  final  acceptance  test  of  the 
system.  The  Vendor  should  be  expected  to  have  his  rep- 
resentative on  call  at  any  time  during  the  1000-hour 
test.  The  Borrower's  dispatcher  and  maintenance  personnel 
should  be  expected  to  participate  in  the  availability  tests. 

Availability  should  be  defined  in  functional  terms.  The 
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system  should  be  considered  fully  available  if  it  is 
capable  of  performing  all  Vendor  supplied  functions.  Loss 
of  peripherals  will  not  normally  count  in  the  accumu- 
lation of  downtime  if  the  loss  does  not  interfere  with 
the  essential  operation  of  system  functions.  The  mal- 
functioning of  one  CRT,  for  example,  will  not  result  in 
downtime  if  a second  CRT  is  operating  correctly,  and 
is  available  for  all  system  functions.  The  loss  of 
electromechanical  devices  will  not  result  in  downtime 
if  the  information  normally  supplied  via  the  devices 
is  available  via  alternate  devices. 

Downtime  is  measured  from  the  time  of  detection  to  the 
time  service  is  restored.  Downtime  clearly  beyond  the 
Vendor's  control  should  not  be  counted.  Power  failures 
and  outages  caused  by  temperature  changes  beyond  those 
guaranteed  by  the  Vendor  should  not  result  in  the 
accumulation  of  downtime.  Diagnosis  and  repair  may  be 
by  the  Borrower's  or  Vendor's  personnel.  Should  the 
downtime  exceed  the  maximum  allowance  specified  during 
the  test,  the  test  should  be  restarted  after  the  Vendor 
has  been  given  adequate  time  to  effect  changes  and/or 
repairs.  The  Vendor  may  elect  to  restart  the  availability 
test  at  any  time. 

G.  Installation 


The  Vendor  should  furnish  plans  and  procedures  necessary  to 
accomplish  a smooth  and  orderly  installation  and  integration. 
The  dates  of  these  submissions  shall  be  compatible  with  the 
overall  system  implementation  schedules.  The  Borrower  should 
furnish  all  architectural  drawings  required  by  the  Vendor  to 
develop  the  plans  and  procedures.  The  Borrower  should  review 
and  approve  all  plans  and  procedures  prior  to  performing  any 
installation. 

1.  Site  Preparation 

The  Borrower  should  prepare  all  sites  for  installation  of 
equipment  in  accordance  with  the  Vendor  furnished  instal- 
lation drawings. 

2.  Master  Station  Equipment 

The  Borrower  should  perform  physical  placement  of  all 
equipment  as  specified,  under  the  technical  guidance  of 
the  Vendor . 
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3. 


Remote  Equipment 


The  Borrower  should  install  all  RTU  equipment  in  accord- 
ance with  procedures  and  drawings  provided  by  the  Vendor. 
The  Borrower  will  perform  operational  checkout  of  each 
RTU  with  the  RTU  test  set.  The  Vendor  should  provide 
field  assistance  as  required  during  the  installation. 

Transducers 

The  Borrower  should  provide  and  install  all  power  system 
transducers . 

5-  Power,  Lighting,  and  Air  Conditioning 

The  Borrower  may  wish  to  provide  the  UPS  and  engine 
generator  set.  The  Borrower  should  provide  for  building 
distribution  and  circuit  protection  of  the  critical  power 
service.  The  Vendor  should  provide  the  requirements  for 
the  number  of  circuits  and  required  rating  of  circuit 
breakers.  The  Vendor  should  provide  general  approval  and 
general  concurrence  on  the  Borrower's  UPS  selection  and 
sizing.  The  Borrower  should  provide  service  to  the 
equipment  cabinets. 

The  Borrower  provides  for  general  service,  non-critical 
power,  lighting,  and  room  and  equipment  air  conditioning. 

6 . Digital  Communication 

The  Borrower  provides  all  communications  circuits  to 
terminated  line  terminal  blocks  mounted  in  a distributing 
frame.  Communications  circuit  protection  should  be  pro- 
vided by  the  Borrower.  The  Borrower  should  also  make 
connections  from  the  digital  equipment  to  the  telephone 
circuit  terminal  blocks  and  to  the  communications  connect- 
ions for  the  RTUs. 

7 . Voice  Communications 

The  Borrower  supplies  all  voice  communications  equipment 
and  circuits.  The  Vendor  should  make  provisions  in  or 
on  the  consoles  to  accept  the  switch  panels  and  speakers. 
The  Borrower  should  install  all  voice  communications 
equipment . 

H.  Operational  Checkout 

As  soon  as  the  energy  control  center  is  placed  into  service,  a 
90  day  moratorium  should  be  declared  on  any  new  software 
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development.  Both  Borrover  and  Vendor  engineering  staffs 
should  be  available  to  answer  any  questions  and  to  respond 
to  any  problems  encountered  by  the  system  operator  and/or 
dispatcher.  For  control  an  indexing  system  should  be  used 
on  all  requests  showing  the  current  status  and/or  completion 
of  each  item  awaiting  final  acceptance  by  the  operators. 

No  changes  to  the  system  should  be  made  until  at  least  90  days 
of  operating  experience  have  been  logged  on  the  program.  All 
subsequent  changes  or  modifications  should  be  coordinated 
with  the  Vendor  prior  to  their  implementation,  to  ascertain 
the  effect  on  the  overall  system  design,  operation,  and 
integrity. 
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I . Elements  of  a Control  Study 


At  some  point,  the  need  to  change,  or  internal  dissatisfaction 
with  existing  operating  methods  and  systems, will  lead  to  a 
management  decision  to  examine  alternative  methods  and  systems 
for  system  monitoring,  control  and  dispatch.  This  is  often 
accomplished  by  appointing  an  internal  task  force  or  study 
group  to  examine  the  problems  as  well  as  potential  solutions, 
including  expected  benefits  and  costs.  Such  studies  can  be  re- 
alized by  the  use  of  a consultant  qualified  in  control  center 
planning.  The  use  of  a consultant  lowers  the  utilities  risk  in 
acquiring  an  adequately  prepared  study.  It  also  aids  in  over- 
coming problems  in  having  the  personnel  available  to  perform 
the  study. 

The  need  for  new  or  modified  control  systems  may  be  based  on: 

° Outmoded  systems 

° Requirements  for  additional  supervisory  control 
° Requirements  for  automatic  generation  control 
° Requirements  for  expansion 
° Requirements  for  system  security  monitoring 
0 Potential  economic  savings 

When  the  Borrower  management  has  concluded  that  some  form  of 
new  or  improved  control  system  is  appropriate  and  justified, 
a requirements  study  can  be  initiated  which  broadly  outlines 
the  total  project.  These  studies  establish  the  broad  scope  of 
the  project , including  major  functions  to  be  performed,  heir- 
archial  system  arrangement,  control  center  location(s), 
building  requirements,  schedule,  budget  estimates  and  staffing 
requirements. 

Major  objectives  during  this  planning  period  are  to: 

° Plan  for  a quality  system  which  performs  as  anticipated 
early  in  its  life  cycle 

° Minimize  system  life  cycle  costs  consisting  of: 
initial  costs 

future  growth  and  expansion  costs 
operating  costs 

° Minimize  risk 
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The  results  of  a requirements  study  are  documented  in  a report 
which  forms  the  basis  for  subsequent  development  of  a system 
procurement  specification. 

The  following  outline  is  typical  of  the  information  to  be 
obtained  and  representative  of  most  Borrower  study  requirements 

1.0  INTRODUCTION 


1.1 

1.2 


1.3 


1.4 


Scope  of  Study 
Study  Goals 

1.2.1  Control  Philosophy 

1.2.2  Communication  Requirements 

1.2.3  Project  Implementation  Personnel 

1.2.4  New  Applications 

1.2.5  Backup  Schemes 

1.2.6  Man/Machine  Considerations 

1.2.7  Project  Schedule 

1.2.8  Project  Costs 

1.2.9  Facility  Requirements 
Study  Operation  Procedures 

1.3.1  Documentation  Review 

1.3.2  Planning  and  Specifications  Guide 
1.3*3  Field  Visits 

1.3.4  Design  Meetings 

1.3.5  Other  Applications 
Report  Structure 


2.0  REQUIREMENT  FOR  A COMPUTER  SYSTEM 


2.1  New  Responsibilities 

2.2  Benefits  of  a Modern  System 

2.3  Conclusions 

3.0  SYSTEM  FUNCTIONS 

3.1  Economic  Dispatch 

3.2  Interchange  Scheduling 

3.3  Supervisory  Control  and  Data  Acquisition 

3.3.1  On/Off  Control 

3.3.2  Control  of  Transformers 

3.4  Data  Processing 

3.4.1  Meter  Error  Analysis 

3.4.2  MVA  Calculation 

3.5  Data  Logging 

3.6  Load  Shedding  and  Restoration 

3-7  System  Peak  Analysis 

3.8  Energy  Accounting 

3.9  Disturbance  Analysis 


IV- 16 


3.10  Storage  and  Retrieval 

3.11  Background  Functions 
3-12  Future  Functions 

4.0  MAN /MACHINE  INTERFACE 

4.1  CRT-Based  Interface 

4.1.1  Expansion  Capabilities  of  CRTs 

4.1.2  Responsiveness  of  CRT-Based  Systems 

4.2  Representative  Alphanumeric  Displays 

4.3  Representative  Limited  Graphic  Displays 

4.4  Console  Configuration 

4.4.1  System  Dispatcher  Console 

4.4.2  Programmer /Engineer /Training  Console 

4.5  Supervisory  Control  Procedures 

4 . 6 Alarming 

4.7  Recording  and  Indicating  Devices 

4.8  Printing  Devices 

4.9  Mapboard 

4.10  Expansion  Capability 

5.0  DESIGN  GOALS 


5.1 

High  Availability 

5.2 

Redundancy  and  Backup  Goals 

5.3 

Reliability  and  Security 

5.4 

State-of-the-Art  Design 

5-5 

Man/Machine  Interface 

5.6 

Conservation  of  Manpower 

5-7 

Minimum  Capital  Investment 

5.8 

Economic  Operating  Costs 

5.9 

Economic  Communicat ion  Costs 

5.10 

Maintainability 

5.H 

Expandability 

5.12 

Line  Span 

6.0  CONFIGURATION  ANALYSIS 

6.1  Common  Configuration  Characteristics 

6.1.1  Common  Hardware 

6.1.2  Common  Software 

6.1.3  RTU  Installations 

6.1.4  Communications 

6.1.5  Optional  Equipment  and  Software 

6.2  Configuration  1 

6.2.1  Operation 

6.2.2  Advantages 

6.2.3  Disadvantages 
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7.0  STAFFING  AND  TRAINING 


I 


7.1  Project  Staffing  and  Personnel 
7-1.1  Project  Manager 

7.1.2  Engineering  Support 
7-1.3  Operations  Support 
7*1.4  Programming 

7.1.5  Maintenance 

7.1.6  Consultants 

7.2  Permanent  System  Staffing 

7.3  Training 

7.3.1  Hardware  Maintenance  Courses 

7.3.2  Software  Courses 

7.3.3  Dispatcher  Training 

8.0  FACILITY  CONSIDERATIONS 

8.1  Physical  Characteristics 

8.1.1  System  Control  Room 

8.1.2  Equipment  Room 

8.1.3  Conference  and  Visitor  Facilities 

8.1. 4 Programming  Facility 

8.1.5  Office,  Maintenance,  and  Storage  Facilities 

8.1.6  Power  Supply  Area 

8.2  Security 

8.2.1  Area  Access 

8.2.2  Smoke  and  Fire  Protection 

8.3  Environment  Characteristics 

8.3.1  Air  Conditioning 

8.3.2  Acoustics 

8.3.3  Lighting 

8.3.4  Electrical  Interference 

8.4  Power  Conditioning 

8.4.1  Power  Supply 

8.4.2  Grounding 

8.5  Communications 

8.5*1  Data  Channel  Requirements 
8.5*2  Voice  Communication  Requirements 

8.5.3  Alternate  Communication  Facilities 

9-0  COST  ANALYSIS 


9.1  Master  Station  Costs 

9.1.1  Hardware  and  Software  Purchase  Costs 

9.1.2  Costs  of  Additional  Services 

9.1.3  Building  Costs 

9.2  Options 

9.3  Remote  Site  Costs 

9.3.1  Remote  Terminal  Units 
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9-3.2  Communications 
9.*+  Operating  Costs 

9.4.1  Personnel 

9.4.2  Future  RTU  Installations 

9.4.3  Communications  - Operation  and  Modifications 

9.4.4  Additional  Operating  Expenses 
9-5  Cost  Summaries 

10.0  SYSTEM  IMPLEMENTATION 

10.1  Purchase  Specifications 

10.2  Major  System  Vendors 

10.3  Evaluation  Report 

10. 4 Final  Contract  Documents 

10.5  Control  and  Monitoring  of  Vendors 

10.6  Inspection,  Test  and  Availability 

10.6.1  Inspection 

10.6.2  Test  Plans 

10.6.3  Test  Reports 

10. 6. 4 Unit  Design  Performance  Tests 

10.6.5  Routine  Quality  Control  Tests 

10.6.6  Factory  Performance  Tests 

10.6.7  Preliminary  Field  Acceptance  Test 

10.6.8  1000-Hour  Availability  Test 

10.7  Installation  Procedures 

10.7.1  RTU  Installation 

10.7.2  Master  Station  Installation 

10.8  Documentat ion 

10 . 9 Payment 

11.0  PROJECT  SCHEDULE 

11.1  Phase  Schedule 

11.2  Building  and  Communicaiton  Schedule 

11.3  Activity  Tabulation 
11. U Cash  Flow  Schedule 

12.0  RECOMMENDATIONS 

12.1  Recommended  Configuration 

12.2  Options 

12.3  Man/Machine  Interface 

12.4  Recommended  Project  Staffing 

12.5  Hardware  Maintenance 

12.6  Software  Maintenance  and  Development 

12.7  Energy  Control  System  Building 

12.8  Communications 

12.9  Recommended  Schedule 
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APPENDICES: 


{ 


A - Definitions 

B - Representative  CRT  Displays 
C - System  Conf iguration 

D - Data  Acquisition  and  Control  Requirements 
E - Communication  Channel  Requirements 
F - Cost  Elements 
G - Inter-Utility  Data  Exchange 


I 
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J. 


Elements  Of  A Control  System  Specification 


A procurement  specification  is  used  to  solicit  technical  and 
price  bids  from  potential  system  suppliers.  To  facilitate 
preparation  of  system  proposals  which  truly  reflect  the  needs 
of  the  utility,  a high  quality  specification  is  essential.  The 
specification  defines  the  required  system,  preferably  in 
functional  terms,  as  well  as  various  supporting  services,  and 
terms  and  conditions.  The  specification  should  be  designed  to 
encourage  bids  from  qualified  suppliers  using  their  standard 
hardware  and  software  modules  where  these  will  satisfy  the 
requirements . 

It  is  necessary,  in  order  to  acquire  a cost  effective  and  well 
performing  system,  to  prepare  a high  quality  specification. 
Specifications  for  these  systems  are  prepared  in  close  coor- 
dination with  the  utility  project  task  force.  The  output  of  a 
previous  requirements  study  forms  the  basis  for  the  specifica- 
tion. Additional  on-site  data  gathering  is  also  normally 
performed.  Individual  sections  of  the  specification  are  then 
assembled  in  draft  form, and  submitted  as  they  are  prepared  to 
the  project  team  for  review  and  comment.  Comments  are  in- 
corporated on  a continuous  basis  until  a final  review  is  made 
of  the  entire  specification.  Following  final  review  and  in- 
corporation of  desired  changes,  the  specification  is  published 
and  made  available  to  potential  system  suppliers  in  the  form 
of  a Bid  Package.  A representative  outline  used  for  a control 
system  specification  is  provided  at  the  end  of  this  section. 

In  some  situations  it  is  more  cost  effective  to  combine  the 
requirements  study  and  the  specification  preparation.  In  these 
situations,  a supplementary  document  is  prepared  which  contains 
information  valuable  to  the  utility  but  not  appropriate  for 
inclusion  in  the  specification.  Information  typically  found  in 
the  supplementary  document  includes: 

° Building  and  facility  requirements 
° Staffing  and  training  recommendations 
° Overall  project  schedule  and  implementation  plan 
° Project  management  recommendations 
0 Definitive  budget  estimates. 

The  following  outline  is  typical  of  the  information  and  organ- 
ization of  a control  system  specification  that  incorporates 
both  the  SCADA  and  Energy  Management  System  (EMS)  function. 
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1.  Introduction 


1.1  General 

1.2  Power  Company  System  Description 

1.3  Energy  Control  System  Overview 

1.3.1  General 

1.3.2  Initial  Functions 

1.3*3  Future  System  Functions 

1.3*4  EMS  Description 

1.3.5  Equipment,  Programs,  and  Services 

1.4  Statement  of  Work  and  Responsibilities 

1.4.1  List  of  Major  Deliverable  Hardware 

1.4.2  List  of  Major  Deliverable  Software 

1.4.3  List  of  Required  Document at  ion 

1.4.4  List  of  Required  Training 

1.4.5  Responsibilities  of  Supplier  and  Purchaser 

2 . Functional  Requirements 

2.1  Initial  System  Functions 

2.1.1  Critical  Functions 

2.1.2  Non-Critical  Functions 

3.  Operational  Requirements 

3.1  Operating  Positions  and  Man/Machine  Devices 

3.1.1  EMS  Control  Center 

3.1.2  Operating  Console 

3.1.3  Static  System  Diagram 

3.1.4  Data  Loggers 

3*1-5  Remote  Console 

3.2  System  Operator  Interaction 

3.3  CRT  Picture  Operation 

3.3.1  Symbol  Conventions 

3-3-2  Color  Conventions 

3.4  Dedicated  Areas  of  Displays 

3.5  Heirarchial  Selection  of  Displays 

3.6  Data  Entry 
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4.  System  Requirements 


4.1  System  Data  Flow 
h.2  System  Configuration 

k.2.1  Communication  Channel  Assignment 

4.3  Availability 

4.3.1  System  Availability 

4.3.2  Mean-Time-To-Repair 

4.3- 3  Final  Acceptance  Demonstration  Availability 

4.3- 4  Availability  Analysis 

4.4  Redundancy /Failover  Criteria 

4.4.1  Computer  Complex  and  Peripherals 

4.4.2  Man/Machine  Interface 

4.4.3  Master  Failover 

4.4.4  Power  Supplies 

4.5  System  Interactive  Man/Machine  Response 

4.6  Data  Scanning  Rates 

4.7  Communications 

4.7- 1  Communication  Channels 

4.7- 2  Communications  Security 

4.8  System  Expansion 

4.9  System  Analysis 

5 • Hardware  Requirements 
5-1  Computer  Subsystem 


5.1.1 

Central  Processing  Unit  (CPU) 

5.1.2 

Direct  Memory  Input /Output  System 

5.1.3 

Main  Memory 

5.1.4 

Mass  Memory 

5.1.5 

Priority  Interrupt  System 

5.1.6 

Computer  Console 

5.1.7 

CPU/CPU  Channel  Interface 

5.1.8 

Watchdog  Timers 

5.1.9 

Keyboard/Printer 

5.1.10 

Card  Reader 

5.1.11 

Power  Fail-Safe 

5.1.12 

Device  Controllers 

5.1.13 

Expansion 
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5.2  Man/Machine  Subsystem 

5-2.1  Operator's  Console  (EMS  Control' Center ) 

5.2.2  Operator's  Console 

5.2.3  Special  Man/Machine  Equipment 

5.2.U  Display  Generation,  CRT  and  Keyboard  Equipment 

5.2.5  Operator  and  Alarm  Loggers 

5.3  Communication  Subsystem 


5.3.1  Data  Channel  Multiplexers 

5.3.2  Data  Channel  Controller 

5.3.3  Communications  Modems 

5-3.H  Communication  Jack  Panel 


5.^4  Remote  Terminal  Units 


5-^.1  Data  Acquisition 

5-H.2  Supervisory  Control 

5.^.3  Communication 

5-^.^  RTU  Design  Characteristics 

5.U.5  Expansion  and  Growth 

5.^.6  Input /Output  Interface  Definition 

5.  U.7  RTU  Portable  Test  Set 


5.5  General  Design  and  Construction  Requirements 
5-5-1  Equipment  Racks 

5.5.2  Special  Test  Equipment  and  Maintenance  Tools 

5-5.3  Workmanship 

5.5. ^  Service  Life 

5-5-5  Equipment  Enclosures 

5*5-6  Personal  Safety  Design 

5.5. T  Maintainability  Design 

5.5.8  Human  Engineering 

5-5-9  Logic  Modules 

5-5.10  Power  Supplies 

5.5.11  Wiring 

5.5.12  Connectors  and  Terminal  Strips 

5.5.13  Cables 

5.5.1^  Heat  Dissipation 

5.5.15  Name  Plates  and  Product  Markings 

5.5.16  Electomagnetic  Interference  (EMI) 

5.5.17  Environmental  Conditions 

5.5.18  Shock  and  Vibration 


5.6  Facility  Requirements 
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6.  Software  Requirements 


6.1  The  Operating  System 

6.1.1  General  Requirements 

6.1.2  Real-Time  Scheduler 

6.1.3  Program  Security 

6.1.4  System  Surveillance  and  Failover 

6.1.5  I/O  Control  and  Processing 

6.1.6  System  Initialization 

6.2  Communications  Software 


6.2.1  Data  Scanning  and  Security  Checking 

6.2.2  Party  Lining  and  Message  Efficiency 

6.2.3  DAta  Conversion  and  Limit  Checking 

6.2.4  kWh  Data  Acquisition 


6.3 


System  Data  Base 


6.3.1  Data  Coding 

6.3.2  Real-Time  Data  Base 

6.3.3  System  Parameter  Data  Base 

6.3.4  Results  Files 

6.3.5  History  File 

6.3.6  Alarm  and  Abnormal  Status  File 

6.3.7  Data  Base  Generation  and  Updating 

6.4  Man/Machine  Software 

6.4.1  CRT  Displays 

6.4.2  Console  Keyboards 

6.4.3  Logger/Printers 


6.5  Programmer’s  Aids 


6.5- 1  Standard  Assemblers  and  Compilers 

6.5- 2  Data  Base  and  CRT  Picture  Generation  and 

Updating 

6.5*3  Utilities 


6.6  Application  Software  Requirements 

6.6.1  System  Monitoring 

6.6.2  System  Alarming 

6.6.3  Supervisory  Control  and  Tagging 

6.6.4  Log  and  Report  Generation 

6.6.5  Load  Forecast  File  Program 

6.6.6  Background  Processing 

6.6.7  Future  Power  System  Applications 
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7.  Supporting  Services 


7-1  Documentation 

7.1.1  System  Design  Specification 

7.1.2  Hardware  Documentation 

7.1.3  Software  Documentation 

7.1. 4 System  Operation  and  Maintenance  Manuals 

7.1.5  Program  Documentation 

7.1.6  Document  Changes 

7.1.7  Documentation  Submittal 
7*1.8  Final  Documentation  Submittal 

7-2  Training 

7.3  Maintenance  Plan  and  Spare  Parts 

7.4  Project  Coordination  and  Mangaement 

8.  System  Implementation  and  Acceptance 

8.1  Program  Schedule 

8.2  Equipment  Delivery  Points 

8.2.1  EMS  Equipment 

8.2.2  RTU  Equipment 

8.3  Supplier  and  Purchaser's  Responsibilities 

8.3.1  System  Design,  Fabrication,  Tests  and  Delivery 

8.3.2  Design  Reviews 

8.3.3  Documentation 

8.3.4  Installation  and  Integration 

8.3.5  Tests  and  Demonstrations 

8.3.6  Training 

8.3.7  Quality  Assurance 

8.3.8  System  Activation 

8.3.9  Performance  Warranty 

8.4  Test  and  Acceptance  Requirements 

8.4.1  Subsystem  and  System  Testing 

8.4.2  System  Acceptance  Tests 

8.4.3  Test  Plans  and  Procedures 

8.4.4  Other  Test  Data  Reporting 

8.4.5  Standard  Test  Equipment 
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9.  Instructions  To  Bidders 


9-1  General 

9-1-1  Intention  to  Bid 

9.1.2  Proposal  Due  Date 
9-1.3  Proposal  Delivery 


9.2  Proposal  Acceptance 

9.2.1  Technical  Proposal  Structure 

9.2.2  Pricing  Proposal 


9.3  Proposal  Evaluation 
9-4  Questions  and  Coordination 

9-5  Bid  Documents 

9*6  Award  of  Contract 

9*7  Disposition  of  Proposal  Documentation 


10.  Terms  and  Conditions 


10.1  Definitions 

10.2  Engineer's  Status 

10.3  Time  of  Commencement,  Prosecution,  and  Completion 

10.4  Prices  and  Method  of  Payment 

10.5  Warranty 

10.6  Precedence 
10-7  Acceptance 

10.8  Progress  Reports 

10.9  Performance  Bond 

10.10  Changes 

10.11  Shipment 

10.12  Notice  of  Shipment 

10.13  Title 

10.14  Default 

10.15  Subcontracts 

10.16  Origin  of  Components 

10.17  Compliance  with  Laws,  Ordinances,  Rules,  and 
Regulations 

10.18  Liens 

10.19  Indemnity  and  Insurance 

10.20  Risk  of  Loss 

10.21  Force  Majeure 

10.22  Patents 

10.23  State  Law  Governing  Contract 

10.24  Assignments 

10.25  Provisions  Relative  to  Employment 

10.26  0SHA  Compliance 
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V.  COST  ANALYSIS 


A.  General 


This  section  presents  costs  for  preparation  of  plans,  studies, 
and  specifications;  designing,  installing,  and  implementing 
the  system;  system  hardware  and  software. 

The  costs  represent  composite  averages  based  on  a review  of 
30  contracts  and  discussions  with  six  manufacturers. 

All  cost  estimates  are  based  on  1979  dollars  and  are  rounded 
off  to  the  nearest  $1,000.  An  allowance  for  inflation  to 
cover  the  period  between  the  date  of  this  document  and  the 
actual  signing  of  a contract  should  be  included  in  the  final 
budget  figures  prepared  by  the  borrower. 

After  determining  the  functions  and  design  goals  to  be  satis- 
fied by  the  supervisory  control  and/or  energy  management,  it 
is  necessary  to  configure  the  proposed  system  accordingly. 

Within  the  framework  of  the  cost  analysis  section,  three  such 
possible  configurations  are  discussed:  (l)  single  processor 

CPU,  (2)  dual  processor  CPU,  and  (3)  dual  processor  CPU's  with 
preprocessors.  While  these  are  not  the  only  configuration 
possibilities  in  a given  control  system  design,  they  are  the 
most  fundamental  and  certainly  the  most  prevalent. 

The  next  paragraphs  of  this  section  briefly  discuss  the  three 
configurations  in  terms  of  how  system  functions  and  design 
goals  are  satisfied,  the  hardware  and  software  involved,  and 
the  advantages  and  disadvantages  of  each.  The  costs  associated 
with  each  configuration  are  also  provided. 

B.  Common  Configuration  Characteristics 


There  are  certain  attributes  which  are  considered  basic  to 
meeting  most  systems  design  objectives,  and  are,  therefore, 
common  to  all  systems  discussed  herein.  The  configurations 
are  discussed  in  depth  in  subsection  C - Operational  Configu- 
ration. In  the  description  of  each  configuration  the  perfor- 
mance criteria  of  individual  components  should  be  specified 
only  to  the  degree  necessary  to  insure  the  achievement  of 
minimum  acceptable  levels  of  system  performance.  Performance 
parameters  of  individual  system  elements  should  be  specified 
only  when  they  are  critical  to  overall  system  performance. 

1.  Common  Hardware 


A mini  mum  level  of  redundancy  is  required  in  any  viable 
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configuration  to  achieve  high  reliability  and  not  subject 
performance  to  the  failure  of  a single  element.  This 
requirement  would  not  be  satisfied  by  the  single  CPU 
configuration  shown  in  Figure  V-l.  This  system  is  de- 
scribed herein  because  it  can  fulfill  almost  all  functional 
requirements,  and  it  is  the  fundamental  systems  building 
block  although  its  low  availability  may  render  it  unaccept- 
able. The  remaining  systems  are  redundant  CPU  configu- 
rations which  are  more  desirable  from  a reliability  stand- 
point. The  auxiliary  memory  and  CRT's  have  also  been 
shown  in  two  configurations:  nonredundant  and  redundant 

with  dual  port  interfaces.  The  reliability  of  these 
three  critical  components,  the  CPU,  auxiliary  memory  and 
CRT's,  their  failover  capabilities  and  their  implementation 
in  the  system  configuration  will  be  of  prime  importance 
in  the  evaluation  of  a Vendor's  offering. 

An  analysis  of  system  tasks  and  their  desired  timing  will 
yield  the  requisite  word  size  'minicomputer'  as  the  CPU. 
Vendor  offerings  will  include  machines  with  word  sizes 
of  l6  bit,  2h  bit,  and  32  bit  machines  and  l6  bit  CPU's 
capable  of  handling  32  bit  and  6U  bit  data  words.  The 
preferences  of  individual  Vendors  in  their  selection  of 
processors  has  made  the  specification  of  a specific  word 
size  unrealistic.  More  important  is  the  arithmatic 
capability  of  the  machine  offered.  Each  Vendor  proposal 
should  be  evaluated  on  its  functional  capabilities  as 
well  as  other  factors  mentioned  herein.  The  pricing  work 
sheets  shown  in  Appendix  C may  be  used  for  proposal 
evaluation . 

All  configurations  contain  a common  set  of  recommended 
control  system  peripherals: 

o KSR  - one  KSR  (teletypewriter  or  CRT  with  hard- 
copy) per  CPU  for  processor  communication  and 
program  control  and  development . 

o Line  Printer  - one  medium  speed  (200  to  U00  lines 
per  minute)  line  printer  for  program  listing, 
large  logs  and  as  a back  up  device  for  the  loggers. 

o Magnetic  Tape  Deck  - for  program  storage,  input 
and  long-term  data  storage. 

o Loggers  - two  logging  typewriters  (120  cps)  should 
be  included  for  alarm  logging,  event  recording 
and  small  to  medium  size  logs.  Normal  operation 
will  find  each  logger  dedicated  to  specific 
functions,  with  failover  to  each  other  or  the  line 
printer . 
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o 


Recorders  - several  dual  pen  recorders  and  single 
pen  recorders  should  be  provided  for  hard  copy 
trending.  Half  of  the  two  pen  recorders  may  be 
assignable  to  any  variables  in  the  data  base,  the 
remainder  may  be  dedicated. 

o Indicators  - several  four  digit  numeric  indicators 
are  to  be  provided.  All  indicators  are  assignable 

Two  operating  consoles  are  considered  basic  to  most 
systems.  The  Control  Operator's  Console,  located  in  the 
control  room,  includes  two  CRT's,  two  keyboards,  and  two 
associated  function  panels. 

A second  console,  the  Programmer/Training  Console,  is 
located  in  the  computer  room.  This  console  is  identical 
in  configuration  and  function  to  the  Control  Operator's 
Console  and  can  be  used  for  development,  debugging, 
training  or  as  a second  Operator's  Console  in  stress  or 
failure  situations. 

Local  I/O  to  interface  indicators,  panel  lights,  and 
analog  telemetry  equipment  is  provided  through  dedicated 
I/O  equipment  designed  for  local  inputs,  or  on  the  con- 
figuration drawings,  through  an  RTU  located  in  the  ECS. 

Table  V-l  is  a list  of  peripheral  hardware  common  to  all 
three  configurations. 

2.  Common  Software 


The  exact  description  of  the  software  to  be  supplied  with 
the  system  is  highly  machine,  and  therefore  Vendor  depen- 
dent. To  briefly  describe  the  software  common  to  the 
configurations,  the  system  has  been  broken  into  general- 
ized programs  or  program  groups.  Software  provided  by 
any  Vendor  can  be  expected  to  follow  the  general  outline 
offered  below.  Table  V-2  is  a list  of  software  common 
to  all  three  configurations.  Experience  has  shown  that 
the  use  of  a consulting  firm  for  the  purpose  of  specifying 
designing,  and/or  evaluating  Vendor  software  offerings 
has  not  only  proven  cost-effective  but  almost  imperative 
in  .complex  operating  structures. 

a.  Basic  Software 


This  package  includes  the  system  'executive'  or  re- 
source management  software,  peripheral  failover 
routines,  machine  failover  routines  for  the  dual  CPU 
configurations,  scheduling  algorithms,  device  handlers 
for  the  computer  peripherals  and  CPU  to  CPU  data  links 
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and  the  software  for  the  interactive  CRT  I/O. 


b.  Data  Base,  CRT  and  Log  Format  Generation 

This  software  allows  the  user  to  add,  delete,  or 
modify  entities  within  the  ECS  to  reflect  changes 
in  the  electrical  network. 

c.  Data  Collection 


This  package  assembles  the  real  time  data  base  by 
polling  the  data  collection  RTU’s  for  both  scheduled 
and  demand  requests.  Data  received  is  checked  for 
validity,  converted  to  engineering  units,  and  stored 
in  the  data  base. 

d.  Generation  Control  and  Application  Software 

The  required  system  functions,  described  in  Section 
III.C  and  Appendix  A,  are  performed  by  this  software. 
Each  function  is  performed  by  routines  which  the 
Vendor  has  implemented  from  a standard  library  of 
application  programs,  or  where  a new  or  different 
requirement  has  been  imposed,  by  software  written 
expressly  for  this  project. 

e.  Communications  Software 


These  specialized  programs  are  required  to  provide 
interconnected  facilities  with  real  time  control  data 
and  detailed  historical  data  for  billing  and  planning 

f .  Diagnostic  Software 


This  package  is  comprised  of  a set  of  diagnostic 
programs  for  each  hardware  component  of  the  control 
system.  Where  possible  on-line  diagnostics  are 
required  to  enable  maintenance  to  proceed  in  parallel 
with  system  operation.  Off-line  diagnostics  are 
provided  for  those  devices,  such  as  main-memory, 
whose  failure  implies  part  of  the  system  be  placed 
off-line . 

g .  Background  Processors 

This  software  allows  performance  of  normal  software 
maintenance,  update  and  test,  as  well  as  generation, 
compilation,  test,  and  initialization  of  new  programs 
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3.  RTU  Installations 


Cost  comparisons  between  analog/KWH  digital  tone  tele- 
metry and  remote  digital  multiplexing  through  the 
facilities  of  a Remote  Terminal  Units  (RTU)  show:  For 

larger  stations  the  RTU,  a device  which  serially  transmits 
strings  of  analog  and  status  data  words  over  a single 
voice  grade  communications  channel,  proves  to  be  more 
economical.  This  economy  is  observed  in  hardware  costs; 
the  cost  of  an  RTU  ranges  from  $3,000  to  $20,000  depending 
upon  the  number  of  points  or  control  options  performed. 

The  development  of  new,  small,  "pole  top"  RTU's,  devices 
functionally  identical  to  standard  RTU's  but  of  limited 
capability,  with  prices  equal  to  or  less  than  comparably 
sized  telemetry  tone  equipment,  has  made  the  utilization 
of  RTU's  for  the  smallest  meter  points  economically 
expedient . 

To  facilitate  cost  estimates,  four  basic  RTU  configurations 
are  discussed: 

o Bulk  delivery  substations 
o Bulk  delivery  line  taps 
o Meter  points 
o Generation  sites 

The  descriptions  below  are  sized  for  typical  station 
configurations  and  do  not  include  provisions  for  imple- 
mented or  nonimplemented  spare  points.  Table  V-3  provides 
costs  for  various  sized  RTU's. 

RTU  for  bulk  delivery  substations: 

o 20  control  outputs  - 8 breakers,  8 recloser 
blocking  controls  and  2 LTC's 

o 8 momentary  change  detection  inputs  for 
reclosing  breakers 

o 30  status  inputs  - 8 supervisory  blocking 
switches,  8 recloser  blocking  switches,  8 
transformer  alarm  contacts,  and  6 miscellaneous 
points 

o 8 analog  inputs  - kV,  MW,  MVAR,  and  LTC 
positions 

o 4 accumulator  inputs  - MWH  and  MVARH 
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RTU  for  bulk  delivery  line  taps: 

o 2 control  points  - 1 breaker  and  1 recloser 
blocking 

o 1 momentary  change  detection  input 

o 8 status  inputs  - 1 supervisory  blocking,  1 
recloser  blocking,  and  4 miscellaneous  points 

o 2 analog  inputs  - MW,  MVAR 

o 2 accumulator  inputs  - MWH,  MVARH 

RTU  for  meter  points: 

o 4 status  inputs  for  miscellaneous  alarms 

o 2 analog  inputs  - MW,  MVAR 

o 2 accumulator  inputs  - MWH,  MVARH 

RTU's  for  generation  sites  are  developed  individually 
due  to  the  differences  among  plants. 

To  minimize  the  initial  system  cost  RTU’s  should  be 
standardized  as  much  as  possible  to  reduce  the  Vendor's 
engineering  charges.  Units  should  also  be  sized  to  include 
later  changes  if  a meter  point  is  to  be  upgraded  to  a 
bulk  delivery  point.  Evaluation  of  Vendor  proposals  should 
include  determining  the  economics  of  upgrading  a meter 
point  RTU  to  one  of  the  larger  configurations.  Additional 
criteria  includes: 

o Maximum  size  of  a 'pole  top'  or  mini-RTU 

o Cost  comparison  of  mini  and  standard  RTU's 

o Acceptability  of  utilizing  two  or  more  'pole 
top'  units  to  control  a single  substation 

o Component  compatability  between  standard  and 
mini-RTU' s 

o Use  of  remote  data  concentrators  of  'report- 
by-exception'  RTU's  to  believe  communications 
channel  bandwidth  usage 

4.  RTU  Communications 


Communications  to  RTU's  located  at  substations  or 
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generation  stations  may  be  via  voice  grade  communication 
circuits,  microwave  LOS,  or  power  line  carrier  of  a 
rate  of  1200  bits  per  second-  In  order  to  reduce  the 
number  of  required  circuits,  RTU's  may  be  'party-lined' 
where  possible,  i.e.  more  than  one  RTU  may  be 
connected  to  each  circuit.  This  loading  allows  sufficient 
free  time  for  the  control  system  to  retrieve  the  remaining 
data  at  slower  scan  rates  and  perform  control  operator 
initiated  control  actions.  Line  loading  can  be  increased 
to  8 or  10  RTU's  per  circuit  if  a circuit  contains  U or 
more  of  the  small  RTU's  described  above  as  bulk  delivery 
line  tap  or  meter  point  RTU's.  Vendors  should  be  asked 
to  detail  their  expected  bandwidth  usage  and  the  potential 
of  their  equipment  to  operate  at  a higher  bit  rate 
(greater  than  1200  bps)  to  increase  channel  efficiency 
with  a corresponding  reduction  in  operating  costs. 

5 . Optional  Equipment  and  Software 

A variety  of  options  have  been  defined  which  are  applicable 
to  any  of  the  following  configurations.  The  options  are 
to  enhance  system  expansion  capability  or  to  improve  the 
operating  capabilities  of  the  control  system.  Table  V-h 
lists  each  option  and  its  estimated  costs.  These  options 
should  be  described  in  detail  in  the  specification.  Their 
incorporation  into  the  control  system  will  be  based  on 
their  cost-effectiveness  as  determined  during  bid  evalua- 
tion. The  following  is  a brief  description  of  each 
optional  hardware  item: 

a.  CRT  Hardcopy 

The  basic  system  will  provide  hardcopy  records  of 
all  alarms.  System  Controller  actions  and  data  entries 
as  they  occur,  and  predefined  logs  of  operations  and 
study  results.  Unique  power  system  conditions  can  be 
recorded  if  the  system  can  also  provide  hardcopy  of 
CRT  displays  on  demand.  This  option  should  include 
the  capability  of  hardcopy  (in  black  and  white)  for 
one-line  diagrams. 

b.  Dynamic  Mapboard  Interface 

This  option  will  provide  for  an  interface  to  drive 
the  indicators  of  a system  mapboard.  The  mapboard, 
if  implemented,  will  be  purchased  separately.  For 
bidding  purposes  the  specification  will  contain  the 
number  and  type  of  indicators,  and  a description  of 
their  operation. 
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c . Single  CRT  Console 

This  option  will  provide  a limited  capability  console 
for  nonoperator  use.  If  purchased  it  will  be  used  as 
a programmer /training  console.  The  console  will  be 
similar  in  design  to  the  two  CRT  consoles,  but  contain 
a single  CRT,  keyboard,  and  function  panel.  The 
telecommunications  facilities  would  be  minimized, 
including  only  a simple  pushbutton  handset.  Writing 
space  and  drawers  are  required  but  may  also  be  re- 
duced in  scope  from  that  required  by  a Dispatcher 
Console . 

d.  Redundant  Keyboard/Function  Panel 

To  allow  two  Dispatchers  to  simultaneously  operate 
from  a single  two  CRT  console,  this  option  would  add 
a second  keyboard  and  function  panel  to  the  console 
equipment.  A switch  matrix  would  allow  either  key- 
board to  access  and  control  both  CRT’s,  or  dedicate 
each  of  the  keyboards  to  a single  CRT. 

6.  Software  Maintenance  and  Development 

Software  maintenance  is  chiefly  concerned  with  the  adding 
of  new  substations  and  dispatch  units,  or  new  points  at 
existing  substations,  specifying  CRT  schematics  and 
devising  more  pertinent  reporting  formats.  If  only  a 
single  programmer  is  to  be  employed,  the  system  is  highly 
vulnerable  to  a loss  of  his  services.  Programmers  tend 
to  find  routine  maintenance  work  dull  and  unrewarding. 

If  the  system  is  to  be  a dynamic  entity,  many  opportunities 
exist  for  the  development  of  sophisticated  monitoring 
techniques  and  analytical  tools  which  not  only  assist  the 
control  operator  in  pinpointing  trouble  conditions  but 
also  delineate  possible  courses  of  action.  No  manufacturer 
can  provide  such  programs;  borrower  programmers  and 
engineers  with  knowledge  of  their  own  electric  system 
are  best  suited  to  develop  these  practical  tools.  Data 
storage,  documentation  and  dissemination  is  also  a field 
where  every  borrower  has  unique  requirements.  The  system 
can  provide  valuable  assistance  to  other  departments  within 
the  company  by  gradually  developing  programs  tailored  to 
the  information  storage  and  retrieval  needs  of  the  company. 

Routine  software  maintenance  should  not  require  downtime. 
The  generation  of  a new  schematic,  for  example,  should 
be  done  via  programmer's  I/O  devices,  Even  if  no  imme- 
diate plans  for  program  development  are  in  evidence,  the 
purchased  systems  should  be  fully  capable  of  future 
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expansion.  This  cannot  he  assured  unless  these  tools 
are  planned  for  and  tested  in  the  initial  system. 

7 . Hardware  Maintenance 


A complete  set  of  master  station  and  RTU  spare  parts 
should  he  stocked  at  the  facility.  Tools  in  the  form  of 
adequate  test  equipment,  diagnostic  programs,  and 
thorough  training  of  personnel  at  the  Vendor's  factory, 
are  requisite  to  maintaining  system  integrity  and  initial 
operating  performance. 

Successful  and  continuous  operation  of  the  system  depends 
on  routine  maintenance  under  an  effective  preventive 
maintenance  program.  Replacing  air  filters,  checking 
cooling  fans,  cleaning  cahinets,  checking  hardware  para- 
meters and  operating  temperatures,  maintaining  discs 
and  adjusting  and  lubricating  electro-mechanical  peripherals 
are  activities  which  must  he  performed  regularly  if  the 
system  is  to  perform  with  a minimum  of  downtime.  The 
computer  should  generate  for  the  use  of  hardware  mainte- 
nance personnel  a periodic  summary  list  of  failed  equip- 
ment and  equipment  with  high  error  counts. 

The  system  should  he  purchased  with  huilt-in  hardware 
checks.  Test  panels  and  customized  test  sets,  as  avail- 
able, should  also  constitute  part  of  the  system.  Hardware 
documentation  consisting  of  physical  and  electrical  plans 
of  cahinets,  consoles,  and  peripherals,  maintenance 
manuals,  instruction  hooks,  reference  manuals,  installation 
wiring  diagrams  and  related  drawings  should  be  stored  at 
the  central  location  in  an  orderly  manner. 

8 . Man/Machine  Interface 


Reliable  operation  of  the  system  requires  a comprehensive 
method  for  system  dispatchers  to  interact  with  the  power 
system.  Errors  can  result  in  overloaded  lines,  damaged 
equipment  and  customer  loss  of  power.  The  recommended 
configuration  based  upon  study  and  analysis  will  provide 
system  dispatchers  with  an  interface  commensurate  with 
their  responsibilities. 

A single  control  operator's  console,  with  redundant  CRT's, 
keyboards,  and  function  panels,  and  operating  space  for 
two  men,  will  prove  sufficient  for  most  systems  initial 
implementation . 

A facility  duplicating  the  control  operator's  interface 
is  recommended  for  use  by  the  programming  personnel.  The 
addition  of  new  RTU's,  new  points,  new  displays,  and 
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modifications  to  existing  displays  will  be  routine  daily 
system  activities.  The  implementation  and  testing  of 
these  additions  and  changes  should  not  rely  on  the  control 
operator's  facilities.  These  tasks  can  be  handled  effi- 
ciently on  separate  devices  removed  from  the  operating 
environment.  Since  many  control  operator  interfaces 
can  be  duplicated  in  this  subsystem,  trainees  may  become 
familiar  with  all  control  system  functions  without  dis- 
turbing normal  control  operator  duties.  The  programmer/ 
console  can  also  serve  as  an  additional  control  operator 
console  during  periods  of  system  disturbance. 

All  CRT  displays  should  utilize  color.  Formats  may  be 
alphanumeric,  limited-graphic  or  a combination  of  both. 
System  parameters  and  devices  should  be  appropriately 
identified  on  each  display.  Dynamic  single  line  substation 
diagrams  may  be  used  to  support  swift,  quiet  and  efficient 
operation. 

A static  mapboard  showing  the  system  control  operator 
dispatches  the  updated  status  of  the  overall  network  is 
recommended.  The  expenditure  to  automate  mapboard 
indications  should  be  ascertained  during  the  time  trail 
procurement.  Vendors  should  be  required  to  price  this 
option  for  possible  enhancement  of  the  system. 

Recorders  are  needed  and  recommended  to  display  system 
frequency,  area  control  error  and  intercompany  power  flows. 
These  recorders  will  provide  the  control  operator  with 
a continuous  record  of  the  major  system  parameters. 
Additional  recorders  and  digital  indicators  may  be  required 
for  display  of  control  operator  assigned  parameters  to 
observe  trends  or  analyze  short-term  phenomena. 

9.  Engineering  and  Implementation  Services 

The  tasks  shown  in  the  following  Table  V-5  must  be  per- 
formed regardless  of  the  configuration  selected  to  assure 
adequacy  of  the  design,  prepare  for  and  complete  install- 
ation, and  to  test  the  equipment,  both  before  and  after 
delivery,  for  conformance  with  the  specification  require- 
ments. The  costs  for  the  engineering  tasks  are  fairly 
constant  for  all  the  configurations  evaluated.  Similarly, 
the  costs  for  purchased  services  do  not  vary  significantly 
with  the  system  configuration.  The  following  descriptions 
summarize  the  various  engineering  and  implementation  tasks 
shown  in  Table  V-5* 

a.  Preparation  of  Specification 

This  item  includes  the  use  of  two  senior  engineers  for 
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the  preparation  of  functional  specifications,  the 
evaluation  of  Vendor  proposals  and  contract  negotia- 
tions with  the  selected  Vendor. 

t>.  Software  Monitoring,  Programming  and  Training 

The  estimate  assumes  that  one  programmer  will  be 
added  at  the  beginning  of  the  project  implementation 
phase,  and  that  the  equivalent  of  a full-time  engineer 
will  work  in  this  area.  This  staff  will  review  all 
Vendor  software  design  and  provide  the  supporting 
data  for  the  application  programs.  Attendance  at 
training  courses  and  system  testing  are  also  included 
in  this  item.  System  test  includes  participation  in 
the  Vendor's  factory  test  and  final  acceptance  tests 
at  the  borrower's  facility. 

c . Hardware  Monitoring,  Power  System  Engineering  and 
Training 

This  activity  will  be  performed  by  the  equivalent  of 
a full-time  engineer,  beginning  with  the  project  imple- 
mentation phase.  It  includes  review  and  approval  of 
design  approaches  and  providing  the  necessary  power 
system  and  communications  data  to  the  Vendor.  Atten- 
dance at  training  courses  and  system  test  are  also 
included  in  this  item.  Costs  are  included  for  two 
hardware  maintenance  technicians  to  attend  the  Vendor's 
hardware  courses  for  approximately  three  months.  These 
maintenance  men  will  participate  in  the  factory  and 
field  acceptance  tests.  The  engineer  will  attend 
basic  training  courses  only  and  supervise  the  conduct 
of  all  tests. 

d.  System  Controller  Support  and  Training 

This  item  represents  the  involvement  of  a control 
system  engineer  in  the  design  review  and  approval  of 
the  control  system  man/machine  interface. 

e.  Installation 


This  item  is  the  estimate  of  the  work  performed  by 
personnel  in  the  installation  of  equipment  at  the 
borrower's  facility.  The  wiring  and  related  tasks 
at  the  center  may  be  purchased  from  a Vendor  or 
wiring  contractor  or  performed  by  borrower  personnel. 
The  estimate  assumes  that  the  system  Vendor  will 
provide  supervision  for  system  installation  and 
start-up  by  borrower  personnel.  The  estimate  covers 
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manpower  to  supplement  the  two  maintenance  technicians 
covered  in  the  items  above. 

f . Factory  and  Field  Acceptance 

The  task  involves  witnessing  factory  and  field 
acceptance  and  availability  testing.  Included  is  the 
cost  of  the  final  update  and  check  out  prior  to 
availability  testing. 

g . Training 

This  item  includes  the  Vendor's  charges  for  training 
courses  given  by  him  or  subcontractors.  Hardware, 
software,  and  system  controller  training  is  included. 

h.  Documentation 

The  Vendor's  cost  for  the  preparation  and  production 
of  all  manuals  and  drawings  is  covered  in  this  item. 

i . Freight  and  Insurance 

Costs  for  packing,  shipping,  and  insurance  coverage 
while  in  transit  and  on-site  prior  to  acceptance  is 
estimated  in  this  item. 

j . Engineering  Services 

This  item  covers  the  costs  of  the  Vendor's  lead  project 
engineers  who  are  responsible  for  the  technical  inte- 
gration of  the  project  including  system  design, 
detailed  specifications  and  test  plans. 

k.  Project  Management 

The  Vendor  can  be  expected  to  assign  a full-time 
manager  to  a project  of  this  scope  to  perform  internal 
scheduling  and  budgeting  activities  and  to  serve  as 
liaison  with  the  borrower  from  the  signing  of  the 
contract  to  completion  of  the  availability  test. 

Design  liaison  with  the  architect/engineer  of  the 
control  system  facility  to  house  the  system  is 
included  in  addition  to  computer  system  design  and 
contract  monitoring. 

l.  General  and  Administrative 

This  item  includes  costs  to  be  incurred  by  borrower 
personnel  not  normally  associated  with  the  technical 
aspects  project.  This  item  will  cover  purchasing 
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costs,  accounting,  and  administrative  charges. 


10.  Master  Station 


Tables  V-6  through  V-8  illustrate  budgetary  costs  for 
the  systems  shown  in  Figures  V-l  through  V-3;  that  is, 
a single  CPU,  dual  CPU's,  and  dual  CPU's  with  preprocessors. 
As  with  all  costs  given  herein,  care  must  be  exercised 
in  their  use.  The  costs  should  be  used  for  budgeting 
purposes  only  and  not  as  a tool  for  evaluating  bids.  This 
is  especially  the  case  for  the  items  shown  in  Tables  V-l 
through  V-5  since  none  of  these  items  represent  dis- 
counted prices  or  the  results  for  a negotiated  bid.  To 
attempt  to  apply  such  factors  would  result  in  many  small 
systems  being  over-budgeted  while  the  medium  to  large 
scale  systems  are  under-budgeted. 

For  example,  for  systems  having  a large  number  of  RTU's, 
the  master  station  prices  will  tend  to  be  discounted  or 
represent  a lower  cost  element.  Whereas  for  those  systems 
having  a small  number  of  RTU's  and  significant  applications 
software,  the  master  station  will  represent  the  largest 
cost  (and  profit)  and  would  be  the  least  discounted. 

Two  other  factors  which  also  have  a large  impact  on  cost 
are  the  CRT  update  time  and  the  frequency  of  execution 
of  applications  software.  If  these  two  factors  are  to 
be  executed  frequently,  for  example,  update  a CRT  page 
every  two  to  three  seconds  and  execute  a large  number  of 
application  software  programs  every  four  to  fifteen  seconds, 
the  CPU's  and  auxiliary  memory  sizes  will  have  to  be 
increased  or  preprocessors  added.  The  end  result  is 
increased  costs. 

Additionally  if  the  standard  software  packages  offered  by 
the  Vendors  require  extensive  modification  software  costs 
may  double  or  even  triple.  As  stated  earlier  Tables  V-6 
through  V-8  are  typical  costs  and  have  a broad  application 
to  a large  number  of  REA.  systems . 

C . Operational  Configurations 

The  following  paragraphs  provide  descriptions  of  three  common 
operational  configurations  used  in  supervisory  and  energy 
control  systems.  The  costs  for  the  master  station  configurations 
1,  2,  and  3 are  given  in  Tables  V-l,  7?  and  8 respectively. 

1.  Configuration  1 

This  arrangement,  shown  in  Figure  V-l,  is  a basic  system 
configuration  which  does  not  have  a high  level  of  system 
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Figure  V-l  Single  Processor  Configuration 


KSR 


v-iU 


availability  but  has  been  shown  here  for  reference 
purposes  only.  A single  CPU  is  utilized.  Attendant  with 
the  CPU  is  a KSR  device  for  programmer  communication.  High 
speed  peripherals,  the  auxiliary  memory,  magnetic  tape, 
line  printer,  loggers,  and  the  console  equipment,  are 
interfaced  via  the  computer  Input/Output  Processor  (IOP). 
The  communications  control  is  also  shown  interfaced 
through  the  IOP.  Slow  speed  devices  such  as  the  recorders 
and  indicators,  may  be  interfaced  through  single  work 
I/O  ports,  or  through  a local  RTU. 

a.  Operation 

All  foreground  and  background  programming  tasks  are 
performed  by  the  CPU.  Background  performance  may  be 
degraded  in  times  when  major  network  emergency  or 
contingency  operations  force  a high  usage  of  CPU 
resources  to  cope  with  the  control  system  requirements. 
Redundancy  is  minimal;  the  loggers  can  fail  over  to 
each  other,  or  to  the  printer.  A single  CRT  failure 
will  not  degrade  system  operation.  Two  keyboard/CRT 
conf igurations  are  available  by  switch  selection. 

(1)  Advantages 

(a)  This  is  the  lowest  cost  system  which  may  meet 
certain  basic  functional  requirements. 

(b)  Maintenance  and  personnel  costs  are  lower 
since  this  system  utilizes  a single  CPU. 

(c)  Development  risk  for  the  basic  system, 
excluding  options,  will  be  low  since  the 
configuration  is  compatible  with  that  offered 
by  many  Vendors. 

(d)  Expansion  increment  available  by  upgrading 
to  configuration. 

(2 ) Disadvantages 

(a)  Growth  in  terms  of  new  application  programs 
are  limited  due  to  the  CPU  loading  imposed 
by  the  basic  functions. 

(b)  System  operation  can  be  halted  by  the  failure 
of  a single  component. 

(c)  This  system  will  have  the  lowest  expected 
availability  (less  than  9W  or  approximately 
3-5  days  downtime  per  year). 


V-15 


(d)  Background  programming  capability  is  re- 
stricted since  the  CPU  will  carry  a sizable 
computational  load.  Compilation  and  assembly 
of  large  programs  would  be  tedious  and  costly. 

(e)  Certain  background  functions  (system  genera- 
tion, data  base  generation)  may  require 
taking  the  system  off  line. 

(f)  As  the  system  expands,  responsiveness  to 
Dispatcher  inputs  could  be  degraded  as 
computational  resources  become  heavily  loaded. 

(g)  New  functions,  when  available,  may  be  difficult 
to  implement  without  procurement  of  main 
memory  increments. 

2 . Configuration  2 

This  system,  described  by  Figure  V-2  provides  a redundant 
CPU  and  auxiliary  memory  to  the  basic  configuration.  All 
peripheral  devices  are  dual  ported  to  allow  access  by 
either  processor.  A CPU  to  CPU  link  is  included  for 
direct,  high  speed  interprocessor  communication. 

a.  Operation 

One  of  the  CPU's  is  designated  as  the  prime  computer 
and  the  other  backup.  Control  of  the  power  system 
will  be  exercised  by  the  prime  CPU.  The  backup 
machine  will  be  available  to  take  control  in  the  event 
of  failure  of  the  prime.  The  prime  will  periodically 
provide  an  output  of  the  system  data  bases  to  the 
backup  computer  auxiliary  memory  so  that  failover 
will  cause  minimal  discontinuity  in  operation.  Access 
to  peripheral  devices  is  controlled  by  hardware  and 
software  to  prevent  simultaneous  access  to  any  device 
by  both  CPU's,  or,  in  the  case  of  a failure,  to 
prevent  the  failed  CPU  from  locking  out  the  backup 
CPU  from  any  peripheral. 

The  backup  machine  will  normally  be  available  for 
background  programming.  Each  CPU  would  be  sized  to 
be  able  to  carry  the  full  foreground  computational 
load  with  little  or  no  loss  of  capability  when  forced 
to  operate  in  a single  CPU  configuration.  Background 
processing  will  be  sharply  degraded  in  the  single  CPU 
mode . 
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(l)  Advantages 


(a)  Can  fully  meet  most  rural  electric  system 
functional  requirements. 

(b)  No  functional  degradation  during  failure. 

(c)  Significant  background  computational  resource 
is  available. 

(d)  New  functions  can  be  incorporated  without 
significant  software  changes  and,  in  most 
cases,  without  the  need  to  purchase  additional 
core  memory. 

(e)  Maintenance  and  personnel  costs  are  moderate 
(more  than  Configuration  1,  but  less  than 
Configuration  3)  since  this  system  involves 
two  identical  CPU's. 

(f)  Development  risk  for  both  the  basic  system 
and  optional  functions  is  low  since  the 
configuration  is  similar  to  that  offered  by 
many  Vendors. 

(g)  Programmers  need  to  be  familiar  with  only 
one  operating  system  and  set  of  programming 
languages.  Company  programming  efforts  may 
be  minimized  by  the  use  of  sophisticated 
language  processors,  data  management  and 
trouble-shooting  debugging  procedures. 

(h)  Availability  is  expected  to  be  about  99-8% 
per  year  or  better. 

( 2 ) Disadvantages 

(a)  Initial  system  cost  is  higher  than  Configura- 
tion 1. 

(b)  As  the  system  expands,  responsivensss  to 
Dispatcher  inputs  could  be  degraded  as  com- 
putational resources  become  heavily  loaded. 

3.  Configuration  3 

This  system,  shown  in  Figure  V-3,  introduces  two  additional 
CPU's  to  the  redundant  system  of  Configuration  2.  The 
new  CPU's  are  used  as  preprocessors  to  relieve  the  main 
processors  of  some  of  their  tasks.  This  system  illustrates 
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Figure  V-3  Dual  Processor  Configuration  with  Preprocessors 


the  communications  equipment  under  the  control  of  the 
preprocessors.  This  configuration  is  included  to  shovr 
the  trend  of  distributed  processing. 

a . Operation 

The  preprocessors  perform  the  polling,  data  collection, 
error  checking,  and  conversion  to  engineering  units. 
Depending  on  the  Vendor's  implementation,  the  pre- 
processors might  additionally  perform  limit  checking 
and  some  man/machine  interface  functions.  As  shown, 
failover  is  accomplished  by  simultaneous  switching  of 
both  the  CPU's  and  the  associated  preprocessors. 
Preprocessors  are  dedicated  to  a single  CPU  and  are 
not  capable  of  operation  with  the  'opposite'  CPU.  This 
configuration  is  shown  in  a general  case,  actual  imple- 
mentation is  highly  Vendor  dependent  and  may  differ  in 
the  allocation  of  functions  and  failure  capability. 

(1)  Advantages 

(a)  Can  fully  meet  virtually  any  borrower's 
requirements  while  maintaining  a better 
distribution  of  computational  load  to  allow 
easier  system  growth. 

(b)  High  responsiveness  to  operator  requests  is 
provided. 

(c)  Shares  the  advantages  of  Configuration  2. 

( 2 ) D i s advant  ages 

(a)  Purchase  costs  are  higher  than  in  basic  dual 
CPU  system.  Configuration  2. 

(b)  Maintenance  costs  are  higher  due  to  increased 
system  complexity. 

(c)  Software  changes  will  probably  have  effects 
in  both  sets  of  computers. 

(d)  Preprocessor  computer  program  generation  and 
testing  requires  either  additional  peripheral 
devices  or  an  emulator  program  in  the  main 
CPU. 

(e)  Programmers  may  be  required  to  learn  either 
high  order  or  two  languages  and  operating 
systems  if  different  CPU's  are  used  for  each 
function. 
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D.  Cost  Summary 


Tables  V-l  through  V-8  provide  a means  of  budgeting  for 
discrete  elements  within  an  energy  control  system  structure 
but  by  themselves  they  do  not  provide  a convenient  means  of 
assessing  the  total  system  costs.  Table  V-9  provides  a cost 
summary  for  a dual  CPU  configuration  similar  to  that  shown 
in  Figure  V-2,  the  most  typical  system  used  in  REA  energy 
control  centers.  Rather  than  provide  a single  average  for 
each  cost  element,  a low  average  and  a high  average  for  each 
of  the  various  costs  shown  is  provided.  The  RTU  costs  are 
excluded  from  the  total  base  system  costs  since  they  are 
unique  in  both  type  and  quantity  for  each  system  undertaken. 
However,  a space  is  provided  at  the  end  of  the  table  as  a 
reminder  for  their  inclusion  in  order  to  establish  the  total 
system  price. 

The  specified  functions  to  be  performed  by  the  energy  control 
system  and  included  in  the  applications  software  are: 

o Data  acquisition  and  monitoring 
o Supervisory  control 
o Load  management 
o Automatic  generation  control 
o Interchange  scheduling 
o Information  storage  and  retrieval 

Costs  for  testing  are  for  a 1,000  hour  availability  test. 

Spare  parts  costs  are  over  a minimum  ten  year  life  of  the 
system. 
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TABLE  V-l 


COMMON  HARDWARE  COSTS 


DISPATCHERS  CONSOLE: 

Limited  Graphic  Color  CRT  (2) 
CRT  Keyboard  (2) 

Function  Pushbutton  Panel  (2) 
Console  Furniture 
Controller  (2) 

$59,000 

TRAINING  CONSOLE: 

Limited  Graphic  Color  CRT,  with  Keyboard 
Function  Pushbutton  Panel 
Console  Furniture 
Controller 

$50,000 

PRINTERS : 

Programmer /Engineer s Typer-KSRs  (2) 
Loggers  (2) 

Line  Printer 
Controllers 

$42,000 

MAGNETIC  TAPE  CONTROLLER  AND  DRIVE: 

$35,000 

RECORDING  AND  INDICATING  DEVICES: 
Trend  Recorders  (10) 

Numeric  Indicators  (10) 

$44,000 

RTU  COMMUNICATIONS  INTERFACE: 
Communication  Controller 
Data  Set/Controllers 
Line  Switching  Unit 
Maintenance  Panel 

$75,000 

LOCAL  INPUT/OUTPUT: 

Local  RTU 

Trend  Recorder  Analog  Outputs 

Numeric  Indicator  Digital  Outputs 

Analog  Outputs 

Digital  Outputs 

KWH  Command  Inputs 

Frequency  Tranducer 

$30,000 

INTERCONNECT  TRANSMISSION  EQUIPMENT: 
KWH  Transmitters  (6) 

Tone  Equipment 
Interconnect  RTU 

$10,000 
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TABLE  V-2 


COMMON  SOFTWARE  COSTS 


BASIC  SOFTWARE:  $40,000 

Operating  System 

• Resource  Management 

• Restart 

• Device  Management 
System  Software 

• Output  Message  Subsystem 

• Scheduler 

• CRT  I/O  Subsystem 
Malfunction  Diagnostics 
Console  Processor 
Mapboard  Driver 
Trending  Software 

DATA  BASE,  CRT  AND  LOG  FORMAT  GENERATION:  $50,000 

DATA  COLLECTION:  $15,000 

RTU  Interface 
Local  I/O 


APPLICATION  SOFTWARE:  $30,000  to  $50,000 

Automatic  Generation  Control  per  program 

Economic  Dispatch  Calculation 
Interchange  Scheduling 
Supervisory  Control 
Data  Processing 
Data  Logging 

Load  Shedding  and  Restoration 
System  Peak  Analysis 
Energy  Accounting 
Disturbance  Analysis 
Storage  and  Retrieval 

COMMUNICATION  SOFTWARE:  $18,000 

Data  Exchange  with  Interconnect  Utilities 

DIAGNOSTIC  SOFTWARE:  $15,000 

On-line  Version,  Each  Peripheral 
Off-line  Version,  Each  Peripheral  and  CPU 

BACKGROUND  PROCESSORS:  $40,000 

Fortran  Compiler  Auxiliary  Memory  Management 

Assembler  Data  Base  Generator 

Source  Editor  CRT  Picture  Compiler 

Utility  Functions 
Test  and  Integration 
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TABLE  V-3 


REMOTE  TERMINAL  UNIT  COSTS 


Type 

Price  Range 

Generation  RTUs 

$10,000  - $19, 000/Unit 

Bulk  Delivery  Substation  RTUs 

$ 8,000  - $18, 000/Unit 

Bulk  Delivery  Line  Tap  RTUs 

$ 3,600  - $ 5,200/Unit 

Meter  Point  RTUs 

$ 4,000  - $10, 000/Unit 

RTU  Installation  Material 

$300/Unit 

RTU  Installation  Time-Average 

3 Manweeks/Unit 
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TABLE  V-4 


OPTIONAL  COSTS 


ECONOMIC  DISPATCH  CALCULATION: 

Optimization  of  Total  Generation  Costs 
Unit  Base  Points  and  Participation  Factors 

$20,000 

LOAD  SHEDDING  AND  RESTORATION: 

Recording  of  Outage  Timing 

Warning  Dispatcher  when  Time  to  Rotate  Outage 

$25,000 

AUTOMATIC  TELEMETRY  OVERRIDE: 

Substitution  of  Data  from  Historial  File 
for  Failed  Metering  Point  Telemetry. 

$20,000 

CRT  HARDCOPY: 

Special  Logger  Characters 
Software 

$ 8,000 

DYNAMIC  MAP BOARD: 

Mapboard  with  Electro-magnetic  Indicators 

Computer  Interface 

Software 

$100,000 

SINGLE  CRT  CONSOLE: 

Limited  Graphic  Color  CRT 
CRT  Keyboard 

Function  Pushbutton  Panel 
Console  Furniture 
Controllers 

$40,000 

REDUNDANT  KEYBOARD/FUNCTION  PANEL: 
CRT  Keyboard 

Function  Pushbutton  Panel 
Switching  Matrix 

$20,000 
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TABLE  V-5 


COST  OF  ENGINEERING  AND  IMPLEMENTATION  SERVICES 


Item 

Description 

Cost 

1 

Preparation  of  system  study  specif ica-  $ 80,000 

tion  bid  evaluation  and  vendor  selection 

2 

Software  monitoring,  programming 
and  training. 

$100,000 

3 

Hardware  monitoring,  power  system 
engineering  and  training. 

$ 75,000 

4 

System  Dispatcher  support  and 
training . 

$ 30,000 

5 

Installation  (RTU's  excluded). 

$ 45,000 

6 

Factory  and  field  acceptance  testing. 

$ 60,000 

7 

Training . 

$ 50,000 

8 

Documentation . 

$ 40,000 

9 

Freight  and  insurance. 

$8,000  to  $16,000 

10 

Engineering  services. 

$100,000 

11 

Project  Management. 

$ 60,000 

12 

General  & Administrative 

$ 40,000 
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TABLE  V-6 


CONFIGURATION  //I  - MASTER  STATION  COSTS 


CPU  (16  - BIT)  WITH  256  KB  MAIN  MEMORY: 

Power  Fail  Safe 

Memory  Protect /Management 

Boot-Strap  Loader 

Interrupt  Control/16  Interrupts 

External  Input/Output  Channel  Processor  (IOP) 

Parity  Trap 

$100,000 

AUXILIARY  MEMORY 

$ 60,000 

SPARE  PARTS  AND  TEST  EQUIPMENT: 

$ 65,000 

COMMON  HARDWARE  FROM  TABLE  V-l 

$345,000 

COMMON  SOFTWARE  FROM  TABLE  V-2 

$328,000 

Software  Subtotal: 

$328,000 

Hardware  Subtotal: 

$570,000 

Total  Configuration  1 Costs  (+10%) : 

$898,000 
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TABLE  V-7 


CONFIGURATION  #2  - MASTER  STATION  COSTS 


CPU  (16  - BIT)  WITH  256  KB  MAIN  MEMORY  (2): 

Power  Fail  Safe 

Memory  Protect/Management 

Boot-Strap  Loader 

Interrupt  Control/16  Interrupts 

External  Input/Output  Channel  Processor  (IOP) 

Parity  Trap 

$200,000 

AUXILIARY  MEMORY  - (2) : 

$120,000 

CPU  TO  CPU  LINK: 

$ 8,000 

PROGRAMMERS  TYPER  (KSR)  FOR  SECOND  CPU: 

$ 7,000 

PERIPHERAL  DEVICE  ACCESS: 

Redundant  Controllers 
Logger 

Line  Printer 
Console 

Communications 
Magnetic  Tape 

Dual  Porting  and/or  Peripheral  Switches 

$ 45,000 

SPARE  PARTS  AND  TEST  EQUIPMENT: 

$ 70,000 

COMMON  HARDWARE  FROM  TABLE  V-l 

$345,000 

SOFTWARE  FOR  REDUNDANCY: 

Failover  Programs 
Intercomputer  Communications 
Auxiliary  Memory  Snapshot 

$ 25,000 

COMMON  SOFTWARE  FROM  TABLE  V-2 

$328,000 

Software  Subtotal 

$353,000 

Hardware  Subtotal 

$795,000 

Total  Configuration  2 Cost  (+^10%)  $1,148,000 
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TABLE  V-8 


CONFIGURATION  #3  - MASTER  STATION  COSTS 


CPU  (16  - BIT)  WITH  256  KB  MAIN  MEMORY  (2): 
Power  Fail  Safe 

$200,000 

Memory  Protect/Management 
Boot-Strap  Loader 
Interrupt  Control/16  Interrupts 
External  Input/Output  Channel  Processor 
Parity  Trap 

(IOP) 

AUXILIARY  MEMORY  - (2): 

$120,000 

CPU  TO  CPU  LINK: 

$ 8,000 

PROGRAMMERS  TYPERS  (KSR)  FOR  SECOND 
CPU  & PREPROCESSORS  (3): 

$ 21,000 

PERIPHERAL  DEVICE  ACCESS: 

Redundant  Controllers 
Logger 

Line  Printer 
Console 
Communication 
Magnetic  Tape 

Dual  Porting  and/or  Peripheral  Switches 

$ 45,000 

PREPROCESSORS  - CPU  (16  - BIT)  WITH 
32  KB  MAIN  MEMORY  (2): 

$ 55,000 

SPARE  PARTS  AND  TEST  EQUIPMENT: 

$ 80,000 

COMMON  HARDWARE  FROM  TABLE  V-l : 

$345,000 

SOFTWARE  FOR  REDUNDANCY: 

Failover  Programs 
Intercomputer  Communications 
Auxiliary  Memory  Snapshot 

$ 25,000 

SOFTWARE  FOR  PREPROSSING: 

Basic  Software  - Operating  System 
Data  Base  Generation 
Intercomputer  Communication 
Diagnostics 

$ 60,000 

COMMON  SOFTWARE  FROM  TABLE  V-2: 
Software  Subtotal 
Hardware  Subtotal 

$328,000 

$413,000 

$874,000 

Total  Configuration  3 Cost  (+10%): 

$1,287,000 
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TABLE  V-9 


COST  SUMMARY 

DUAL  CPU  CONFIGURATION  - 256  KB  MAIN  MEMORY 


Item 

Low  Average 

High  Average 

CPU’s 

$ 275,000 

$ 500,000 

Auxiliary  Memory 

50,000 

85,000 

Local  I/O 

20,000 

40,000 

Communications  Interface 

55,000 

100,000 

Spare  Parts 

150,000 

200,000 

Peripherals 

Magnetic  Tape 

15,000 

19,000 

Line  Printer 

15,000 

17,000 

Loggers 

10,000 

12,000 

Miscellaneous 

18,000 

25,000 

Man/Machine  Interface 

Display  Generators 

30,000 

38,000 

Monitors 

10,000 

16,000 

Keyboards 

5,000 

7,000 

Function  Panels 

2,000 

5,000 

Consoles 

7,000 

12,000 

Recorders 

40,000 

45,000 

Indicators 

6,000 

12,000 

Basic  Software 

35,000 

80,000 

Application  Software 

250,000 

375,000 

Training 

35,000 

60,000 

Installation  (RTU's  excluded) 

45,000 

65,000 

Testing 

29,000 

45,000 

Insurance  & Freight 

8,000 

16,000 

Document at ion 

30,000 

60,000 

Engineering 

190,000 

300,000 

Total  Base  System  Price 

$1,330,000 

$2,134,000 

RTU's  - Use  Table  V-3 

Generation 

Bulk  delivery  line  tap 

Bulk  delivery  substation 

Meter  point 

Total  System  Price 
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APPENDIX  A 


APPLICATION  PROGRAMS 


A.  General 


The  power  application  programs  described  in  this  section  fall 
into  several  functional  categories.  These  categories  are  real 
time  dispatch,  dispatch  studies,  utilities,  advanced  dispatch 
functions,  off-line  dispatch  of  scheduling,  and  system  security 
aids.  The  illustration  on  th§  following  page  shows  this  cate- 
gorization of  application  functions. 

The  real  time  dispatch  functions  are  those  which  have  tradition- 
ally been  a part  of  electrical  power  dispatch  offices:  automatic 
generation  control,  economic  dispatch,  and  interchange  scheduling 
The  dispatch  studies  include  economy  transaction  evaluation 
and  production  costing,  and  the  advanced  dispatch  functions 
include  the  use  of  penalty  factors  and  distribution  factors  from 
a real  time  load  flow,  for  the  economic  dispatch  and  study 
functions . 

The  system  utilities  include  a variety  of  data  recording, 
analysis,  and  monitoring  functions  - data  logging,  overload 
monitoring,  and  reserve  monitoring. 

The  scheduling  and  security  analysis  programs  include  some  of 
the  more  advanced  software  available  in  the  industry  today. 

The  scheduling  functions  include  an  advanced  unit  commitment 
program.  The  security  analysis  programs  include  A.C.  contingency 
analysis  programs,  in  both  real  time  and  study  versions,  a 
dispatcher  or  operator  oriented  load  flow,  and  a state  estimation 

The  implementation  of  the  entire  set  of  these  applications  pro- 
grams would  result  in  one  of  the  more  sophisticated  and  func- 
tionally powerful  dispatch  offices  in  the  world  today.  These 
applications  programs  have  been  designed  to  conveniently  bring 
the  dispatcher  the  benefit  of  state-of-the  art  analytical  tools 
for  secure  and  economic  operation. 

A description  of  the  standard  AGC  system  is  presented  along 
with  a brief  description  of  each  of  the  advanced  application 
functions.  The  descriptions  are  not  intended  as  a complete 
functional  specification  but  merely  serve  to  identify  the 
scope  of  software  functions. 

B . Application  Programs 

1 . Digital  Automatic  Generation  Control  (AGC) 

This  section  describes  an  Automatic  Generation  Control 

System  (AGC),  providing  general  information  on  the  AGC 
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system  as  a whole, and  providing  detailed  descriptions  of 
the  three  software  subsystems: 

° The  Load  Frequency  Control  Subsystem 
The  Interchange  Scheduling  Subsystem 
The  Economic  Dispatch  Subsystem 

The  displays,  printouts,  alarms,  man-machine  interface, and 
operating  modes  of  the  AGC  system  are  also  described  in 
this  section. 

The  basic  purpose  of  the  AGC  system  is  to  assign  automati- 
cally controlled  generation  in  such  a way  that  interconnected 
system  load  is  being  supplied.  The  generation  assignment 
is  made  such  that  the  desired  interchange  schedule  is 
maintained  and  the  generation  is  done  as  economically  as 
the  interconnected  system  conditions  permit. 

a . An  Overview  of  the  AGC  System 

At  frequent  intervals, the  Energy  Management  System  scans 
the  area  for  the  following  quantities: 

° Actual  Tie  Line  Power  Flows 
0 Actual  Area  Frequency  Deviation 

Actual  Output  Power  of  each  Generator  Unit 

The  tie  line  power  flows  and  the  frequency  deviation  are 
used  by  the  LFC  subsystem  of  the  AGC  system  in  the 
calculation  of  Area  Control  Error  (ACE).  ACE  is  measured 
in  units  of  power  such  as  megawatts.  It  represents  the 
total  error  between  the  interchange  being  demanded  and 
being  supplied, as  well  as  a megawatt  adjustment  for  the 
frequency  error . 

It  is  the  responsibility  of  each  area  in  an  interconnected 
system  to  minimize  ACE  at  all  times.  When  the  value  of 
ACE  is  not  zero,  it  indicates  that  an  area  is  either 
not  maintaining  the  desired  scheduled  interchange,  that 
it  is  not  doing  its  share  in  the  control  of  interconnection 
system  frequency,  or  both. 

Once  ACE  has  been  determined,  the  LFC  subsystem  must 
distribute  this  error  in  the  power  needed  among  each 
of  the  controllable  generators.  Once  the  distribution 
is  made,  the  power  increment  from  each  controllable 
generator  is  converted  into  the  required  raise  or  lower 
pulses . 


In  addition  to  the  control  of  generator  output  power 
being  done  by  the  LFC  subsystem,  a means  must  be 
provided  for  altering  the  scheduled  interchange  power. 

The  interchange  scheduling  subsystem  is  used  for  entering 
new  scheduled  interchange  data,  computing  the  net  inter- 
change power,  and  for  transmitting  the  schedule  change 
data  to  the  LFC  subsystem. 

b . Load  Frequency  Control  Subsystem 

The  Load  Frequency  Control  (LFC)  subsystem  contains  the 
following  tasks  which  are  needed  to  carry  out  its 
portion  of  the  Automatic  Generation  Control  functions: 

° Area  Control  Error  Task 
0 Power  Allocation  Task 
° Generator  Pulser  Task 

There  are  a number  of  restrictions  placed  on  the  execu- 
tion intervals  of  the  tasks  in  the  LFC  subsystems. 

First,  for  good  control  action,  the  tasks  should  not  be 
executed  less  frequently  than  once  every  ten  seconds. 
Next,  when  considering  CPU  loading,  the  most  frequent 
execution  of  the  LFC  subsystem  is:  the  Area  Control 

Error  Task  once  every  two  seconds;  the  Power  Allocation 
and  Generator  Pulser  Tasks  at  an  integer  multiple  of 
the  ACE  Task  Interval. 

A further  restriction  is  placed  on  the  Power  Allocation 
and  Generator  Pulser  Task,  they  must  always  have  the 
same  execution  interval.  Finally,  the  execution  interval 
of  the  latter  two  tasks  must  be  an  integer  multiple  of 
the  execution  interval  of  the  Area  Control  Error  Task. 
These  last  two  LFC  software  modules  should  cause  no 
practical  limitation  for  AGC  system  users. 

The  Area  Control  Error  Task  smoothes  the  scanned  area 
quantities  and  calculates  the  smoothed  value  of  the 
Area  Control  Error.  On  completion  of  this  task,  the 
Power  Allocation  Task  may  be  called  into  execution, 
depending  on  the  ratio  of  the  execution  intervals. 

The  Power  Allocation  Task  allocates  the  smoothed  Area 
Control  Error  among  the  controlled  generators  using  the 
current  base  points  and  percent  participation  factors. 

The  use  of  these  quantities  during  the  allocation  allows 
economy  to  be  considered.  This  task  then  converts  the 
power  allocated  to  each  generator  into  raise  or  lower 
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pulses  for  each  generator.  On  completion,  this  task 
calls  the  Generator  Pulser  Task.  : This  latter  task 
uses  SEMS  to  transmit  the  raise  or  lower  pulses  to  the 
controlled  generators. 

AGO  uses  the  standard  man-machine  interface  and  control 
ability  provided  by  the  SCADA  system, with  the  addition 
of  the  generator  unit  controllers. 

Frequency  bias  and  scheduled  frequency  for  time  correc- 
tions are  operator  enterable  via  CRT.  Scheduled  net 
interchange  is  calculated  from  data  obtained  from  the 
interchange  Scheduling  Program. 

The  Area  Control  Error  is  capable  of  being  controlled 
with  a minimum  amount  of  control  action  (i.e.,  short 
term  cyclic  loading  of  generators  is  suppressed  as  much 
as  possible  without  excessive  loss  of  control  effective- 
ness). This  is  accomplished  by  digital  smoothing  of 
frequency  deviation,  actual  tie  line  flow  value,  and 
actual  generator  megawatt  outputs.  In  addition,  the 
ACE  value  is  digitally  smoothed  again  with  a double 
level  digital  filter.  By  proper  choice  of  the  above 
set  of  smoothing  constants,  the  high  frequency  component 
in  the  ACE  errors  can  be  effectively  filtered.  The 
resultant  smoothed  value  of  ACE  represents  only  the 
longer  term  error  on  the  power  system. 

When  the  ACE  consists  entirely  of  noise  (non-controllable 
components )# the  regulating  units  are  controlled  at  their 
economic  base  points. 

Control  action  shall  be  allocated  to  the  units  on 
control  according  to  their: 

0 Control  mode 

° Participation  factors  (Economic  and  Regulation) 

° Deviation  from  economic  level 

Control  action  shall  be  constrained  by  unit  operating 
limits,  response  rate  limits,  and  anticipated  unit 
response  to  previously  taken  control  action. 

Emergency  assist  action  is  provided  using  the  ACE  level 
mode.  Normal  EDC , Permissive  EDC , and  Assist  actions 
are  used  for  the  descriptions  of  these  modes  in  the 
section  describing  AGC  modes  and  generator  modes  (all 


changes  in  LFC  subsystem  modes  result  in  alarms  to 
the  AGC  operator). 

The  LFC  subsystem  includes  an  automatic  inadvertent 
interchange  payback  capability.  The  operator  is  able 
to  monitor  or  override  this  feature  through  the  CRT. 

AGC  controls  to  generators  are  suspended,  but  ACE 
computations  shall  continue  when: 

AGC  is  in  flat  frequency  control,  or  tie  line 
bias  control,  and  the  system  frequency  tele- 
metering fails. 

° AGC  is  in  flat  tie  line  control,  or  tie  line 
bias  control  and: 

- Tie  line  MW  telemetering  fails,  or 

- The  actual  net  interchange  deviates  from  the 
scheduled  net  interchange  by  greater  than 

a preset  limit. 

The  operator  is  able  to  reset  control  when  the  problem 
has  been  corrected. 

The  following  conditions  cause  the  LFC  subsystem  to 
suspend  sending  control  pulses: 

O 

Excessively  large  smoothed  ACE  values. 

° Excessively  large  frequency  deviation  values. 

To  observe  the  long  term  behavior  of  the  LFC  subsystem, 
the  following  parameters  are  provided  on  the  CRT: 

O 

The  hourly  mean  value  of  ACE. 

The  hourly  standard  deviation  of  ACE. 

° The  hourly  maximum  value  of  ACE. 

In  addition,  the  hourly  number  of  control  pulses  that 
are  sent  is  displayed. 

c . Interchange  Scheduling  Subsystem 

The  Interchange  Scheduling  Subsystem  translates  generation 
schedules  from  the  static  operator  input  format  to  the 
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dynamic  input  required  by  the  load  frequency  control 
program. 

The  Interchange  Scheduling  Subsystem  maintains  the  files 
of  ongoing  and  future  power  transactions  with  different 
companies.  It  processes  these  transactions  at  the 
appropriate  time,  and  provides  the  net  schedule  and  the 
ramp  rate  as  an  input  to  the  load  frequency  control 
program. 

The  following  functions  and  capabilities  are  included: 

° A separate  page  of  schedules  per  facility 

° Allows  operator  to  enter,  delete  or  modify  any 
schedule 

° Capability  to  enter  schedules  one  month  in 
advance 

0 Each  schedule  to  have: 

Start  time 
Stop  time 
Ramp 

Duration  of  ramp 
Net  schedule 
Type  of  transaction 
Local  price 
Foreign  price 

0 Transactions  with  a company  to  be  displayed  in 
chronological  order  by  start  time 

0 Validate  operator  entered  data. 

° Notify  operator  five  minutes  prior  to  start 
of  schedule 

0 Log  all  changed  schedules 

0 Calculate  net  schedule  and  net  ramp  and  pass 
to  load  frequency  program 

° Delete  completed  schedules 

The  Interchange  Scheduling  functions  are  performed  by 
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using  two  separate  tasks.  The  generation  schedule  files 
are  updated  and  maintained  by  the  task  schedule  file 
(SCHFIL).  SCHFIL  receives  new  or  changed  schedules, 
performs  validation  of  operator  entered  data,  does 
logging, and  sorts  the  schedule  files  chronologically. 

Generation  schedules  are  grouped  by  the  company 
participating  in  the  transaction.  There  can  be  one  or 
more  pages  per  company.  The  operator  can  select  one 
or  more  schedules  in  a page  for  one  of  two  functions, 
either  Entry  or  I>eletion.  Previously  entered  schedules 
which  are  to  be  modified  are  processed  via  the  entry 
function. 

Schedules  (including  blank  schedules)  can  be  selected 
for  processing  by  entering  an  asterisk  in  the  Select 
Field  for  that  schedule. 

To  delete  schedules,  the  operator  selects  the  schedules 
he  wants  to  delete  and  then  executes  the  delete  function. 

To  enter  or  modify  schedules,  the  operator  writes  or 
overwrites  on  Selected  Schedules  and  then  executes  the 
Enter  function.  The  schedules  will  appear  packed  and 
sorted  within  the  company,  in  chronological  order  by 
start  time. 

Any  schedules  which  have  an  invalid  operator  entry  will 
be  rejected  and  lost,  the  operator  will  be  notified  of 
this  via  a message  on  the  top  system  line. 

In-place  entries  on  the  screen  for  schedules  which  have 
not  been  Selected,  will  be  rejected  and  lost.  The  pre- 
vious data  will  reappear  on  the  screen.  No  message 
will  be  generated. 

A duplicate  copy  of  the  schedule  file  is  maintained  to 
preserve  the  integrity  of  the  data  base  against  operator 
entry  error,  and  to  distinguish  modified  schedules.  One 
copy  of  the  file  is  used  for  operator  display  and  entry. 
The  other  copy  is  maintained  and  updated  with  valid 
operator  entries  by  SCHFIL. 

Both  copies  will  have  the  FORTRAN  Interface  Common 
structure  and  will  reside  on  disk. 

NXTSCH  accesses  the  AGC  common  to  put  in  the  values  of 
the  net  schedule  and  ramp  rate. 
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d . Economic  Dispatch  Control  Subsystem 


The  Economic  Dispatch  Control  (EDC)  Subsystem  contains 
the  following  tasks: 

° Economic  Dispatch  Control  Task 

° Spinning  Reserve  Task 

° Incremental  Cost  Curve  Calculator  Task 

Much  more  latitude  is  permitted  in  the  selection  of  the 
execution  intervals  of  the  EDC  subsystem.  The  Economic 
Dispatch  Control  Task  and  the  Spinning  Reserve  Task 
need  not  use  the  same  execution  interval.  These  intervals 
may  be  as  frequent  as  once  every  two  minutes.  However, 
no  upper  limit  on  execution  interval  exists.  Under 
certain  circumstances,  a borrower  may  indeed  choose  to 
have  no  EDC  calculations  being  performed.  If  this 
method  of  operation  is  selected,  the  AGC  operator  must 
manually  enter  the  base  points  and  percent  participation 
factors . 

The  Economic  Dispatch  Control  Task  is  the  first  task 
of  the  EDC  subsystem  to  be  executed  at  each  execution 
interval.  This  task  determines  the  most  economical 
distribution  of  power  among  the  controllable  generators 
that  is  needed  to  supply  the  current  power  system  load. 

In  addition,  the  generator  power  output  is  checked  by 
the  Spinning  Reserve  Task  to  assure  that  the  spinning 
reserve  requirements  are  met.  The  Incremental  Cost 
Calculation  Task  is  not  scheduled  for  repetitive  exe- 
cution. The  AGC  operator  will  execute  this  task  each 
time  the  generator  fuel  costs  or  the  generator  incre- 
mental heat  rate  curves  are  changed.  This  task  will  be 
executed  on  the  background  CPU.  The  task  is  used  to 
calculate  the  incremental  cost  curves  from  generator 
fuel  cost  and  generator  incremental  heat  rate  curve  data 
stored  on  the  disk.  It  need  only  be  called  each  time 
this  stored  data  gets  updated. 

Although  the  EDC  subsystem  is  scheduled  for  repeated 
execution,  the  AGC  operator  may  wish  to  cause  a special 
execution  at  some  given  time.  This  can  be  accomplished 
using  the  CRT  displays  for  AGC. 

The  Economic  Dispatch  Control  Subsystem  allocates  gener- 
ation among  controllable  generators  in  such  a way  as  to 
minimize  system  production  cost  to  meet  the  system  load. 
Each  time  the  EDC  executes,  it  determines  the  economic 
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distribution  of  the  load  among  the  controlled  generators. 
The  requirement  for  each  generator  is  referred  to  as  that 
generator's  base  point  and  each  generator  is  given  a 
percent  participation  factor  which  is  derived  from  its 
invremental  cost  curve. 

There  are  two  modes  of  EDC  operation: 

EDC  on 

EDC  off 

The  Economic  Dispatch  Program  executes  periodically, 
when  a unit  is  placed  on  or  off  automatic  control,  or 
when  the  deviation  from  the  previous  generator  base 
points  exceeds  preset  limits.  The  program  calculates 
desired  generation  levels  and  participation  factors  for 
regulated  units,  unit  and  system  fuel  costs,  and  trans- 
mission losses.  The  system  transmission  losses  are 
determined  with  the  B matrix  and  BQ  vector  using  the 
standard  quadratic  formula  for  losses. 

The  EDC  has  the  capability  of  containing  three  unique 
incremental  heat  rate  curves  for  each  generating  unit: 

° Fuel  Type  1 

° Fuel  Type  2 

° Fuel  Type  3 

Any  one  of  three  different  incremental  heat  rate  tables 
can  be  utilized  for  each  generator.  Modification' of 
fuel  costs  and  fuel  type  is  done  using  the  CRT.  Modifi- 
cation of  the  heat  rate  tables  can  also  be  done  through 
the  CRT  by  using  the  SEMS  Editor.  This  would  typically 
require  a programmer's  skills. 

The  operator  shall  have  the  capability  of  entering  a 
system  regulating  margin  (time  limited  reserve)  require- 
ment that  is  to  be  available  during  emergency  assist. 

This  is  done  using  the  Spinning  Reserve  Task. 

The  EDC  calculation  executes  as  often  as  once  every  two 
minutes.  It  uses  the  same  unit  operating  limits  that 
the  LFC  subsystem  uses. 

° Unit  operating  low  limit 
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° Unit  dispatcher's  high  limit 

° Unit  operating  high  limit 

As  long  as  all  units  are  below  the  dispatcher's  high 
limit,  these  limits  are  used.  When  all  units  reach 
the  dispatcher's  high  limit,  both  LFC  and  EDC  subsystems 
change  to  the  operating  high  limit.  Alarms  are  given 
when  this  occurs. 

The  dispatcher's  high  limits  allow  the  operator  to 
specify  a unit  spinning  reserve  for  each  generator  which 
LFC  must  respect  until  system  conditions  require  that 
reserve  be  used  to  meet  excessively  high  system  loads. 

Pertinent  economic  dispatch  calculated  values,  such  as 
system  incremental  cost,  unit  base  points,  and  unit 
participation  factors,  are  displayed  via  CRT  to  the 
operator . 

e . Information  Flow  Description 

The  information  needed  from  the  power  system,  such  as  tie 
line  power,  frequency  deviation,  and  generator  power,  is 
obtained  using  the  Energy  Management  System  (SEMS). 

Other  information  may  be  input  by  the  AGC  operator  using 
the  CRT's.  This  information  is  deposited  in  the  appro- 
priate AGC  data  files. 

Data  files  organization  is  important  to  the  information 
flow  and  efficient  operation  of  the  AGC  system.  Each 
subsystem  may  have  one  or  more  data  files  for  its  own 
use.  Each  of  these  data  files  are  part  of  the  general 
data  base. 

Communication  of  the  data  among  the  AGC  subsystems  is 
handled  by  the  AGC  data  file.  By  organizing  the  data 
files  in  this  manner,  a significant  reduction  is  made  in 
the  maximum  size  of  core  needed  for  the  individual  sub- 
systems during  execution. 

An  important  element  in  the  information  flow  is  the  AGC 
operator.  By  observing  the  displays,  he  can  monitor  the 
status  of  the  power  system.  As  unusual  conditions  arise, 
the  AGC  operator  can  interact  with  the  AGC  system  through 
the  CRT's.  The  CRT's  can  be  used  to  automatically  update 
the  appropriate  data  files  when  data  changes  are  needed. 
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f . AGC  CRT  Displays 


Table  A-l  lists  the  eight  CRT  possible  displays  that 
are  used  with  a typical  AGC  system.  The  figure  lists 
the  number  of  pages  for  each  CRT  for  a typical  AGC 
installation.  For  an  application  with  a small  number 
of  generators,  some  of  the  multiple  page  displays  may 
be  combined.  For  an  application  with  a large  number 
of  generators,  each  page  displaying  generator  data  may 
require  more  than  one  CRT  display  page.  Each  of  these 
displays  will  be  discussed  briefly. 


Table  A-l 

NUMBER 

DISPLAY  OF  PAGES 

AGC  Status  and  Control  Summary  1 

AGC  Alarm  and  Acknowledge  Page  1 

Unit  Generation  and  Summary  2 

Tie  Line  Power  Flow  Setup  1 

Interchange  Transactions  Setup  AR 

AGC  Data  Setup  3 

Economic  Dispatch  Control  Setup  1 

Spinning  Reserve  Setup  1 


( 1 ) AGC  Status  and  Control  Summary 

The  AGC  Status  and  Control  Summary  Display  provides 
information  of  all  the  key  AGC  quantities.  The 
operator  can  see  at  a glance  what  the  area  status 
is,  and  which  of  the  control  modes  of  AGC  operation 
are  currently  being  used. 

Of  primary  interest  to  the  AGC  operator  is  the 
current  ACE  value,  the  area  load,  the  on-line  capa- 
city, and  the  area  spinning  reserve. 

The  AGC  operator  can  use  this  page  to  observe  the 
system  status,  and  can  modify  the  AGC  system  opera- 
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tion  by  selecting  other  states  for  the  various 
modes . 

( 2 ) AGC  Alarm  Acknowledge  Page 

This  page  is  used  by  the  AGC  operator  to  acknow- 
ledge the  alarms  for  the  subsystem.  The  acknow- 
ledge point  for  each  alarm  is  at  the  far  left  of 
each  line.  The  alarm  state  and  alarm  description 
identify  the  alarm  that  is  to  be  acknowledged. 

Any  alarms  awaiting  acknowledgement  will  be  shown 
flashing  on  and  off. 

The  alarm  description  precedes  the  repeated  alarm 
acknowledge  points  and  points  for  each  generator 
in  the  system. 

( 3 ) Unit  Generation  Summary 

The  unit  generation  summary  uses  two  pages,  both 
organized  in  the  same  way.  Each  row  is  devoted  to 
a separate  generator  unit.  Each  column  is  used  to 
display  and/or  enter  the  data  for  each  generator. 

The  AGC  operator  uses  the  page  to  enter  generator 
limits,  base  points,  and  present  participation 
factor . 

(4)  This  display  is  used  by  the  AGC  to  observe  and  update 
the  data  used  for  each  tie  line.  Each  row  represents 
a separate  tie  line.  There  are  three  types.  First, 
the  tie  lines  which  are  normally  being  scanned; 

this  display  would  show  the  power  flowing  on  that 
tie  line  under  the  telemetered  tie  line  flow  column. 
Next,  there  are  tie  lines  which  ordinarily  are  being 
scanned, but  are  currently  not  due  to  equipment 
failure.  Here,  the  AGC  operator  enters  an  estimated 
value  for  this  line's  power  flow  into  the  substituted 
tie  line  flow  column.  Finally,  the  untelemetered 
tie  line  flow  column  shows  the  tie  lines  which  are 
never  scanned,  because  no  telemetering  equipment 
exists.  The  operator  must  enter  an  estimated  value 
for  the  actual  flow  on  each  of  these  types  of  tie 
lines . 

At  the  bottom  of  this  display  are  the  total  power 
flows  for  the  various  types  of  tie  lines. 
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(5) 


Interchange  Scheduling  Setup 


The  AGC  operator  uses  this  display  to  enter  the 
desired  interchange  schedules  for  a given  company. 
Each  entry  occupies  one  row  on  the  display,  allowing 
30  entries  on  a single  page.  There  is  one  month 
time  constraint  on  the  future  start  and  stop  times 
for  entries.  There  will  be  one  display  of  this 
type  for  each  company  with  which  interchanges  are 
scheduled . 

( 6 ) AGC  Data  Setup 

This  three  page  display  is  used  to  enter  data  to 
the  AGC  system.  On  page  1 are  such  items  as  alarm 
limits,  frequency  bias,  number  of  generators,  and 
number  of  tie  lines. 

Most  of  the  items  on  page  2 and  3 are  entered  when 
the  system  is  first  started  upland  rarely  changed 
again.  Page  2 is  used  to  enter  the  generator 
control  constants  for  the  low  end  at  the  generator 
operating  range.  Page  3 is  used  to  enter  the 
control  constants  for  the  high  end. 

( 7 ) Economic  Dispatch  Control  Setup 

This  CRT  may  be  used  for  entering  new  base  points 
and  percent  participation  factors. 

(8)  Spinning  Reserve  Setup 

This  display  is  used  by  the  AGC  operator  to  set  up 
the  data  for  the  Spinning  Reserve  Task.  Data  needed 
for  the  spinning  reserve  calculation  is  entered 
using  this  CRT.  The  spinning  reserve  results  for 
each  generator,  as  well  as  totals,  are  displayed 
on  this  page.  The  spinning  reserve  alarm  is  also 
acknowledged  on  this  page. 

g . AGC  Modes  of  Operation 

There  are  a number  of  modes  of  operation  in  the  AGC 
system.  Most  of  the  modes  are  used  to  modify  or  indicate 
the  status  of  the  LFC  subsystem.  However,  several  are 
used  to  indicate  the  status  of  the  Interchange  Scheduling 
Subsystem. 
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The  following  modes  are  used: 


° LFC  Control  Mode 
0 ACE  Calculation  Mode 
° Schedule  Change  Mode 
° Time  Correction  Mode 
° LFC  Data  Base  Mode 
0 Generator  Control  Mode 
° Tie  Line  Scan  Status  Mode 
° Economic  Dispatch  Mode 
° Penalty  Factor  Mode 
° Spinning  Reserve  Mode 


The  most  important  mode  in  the  AGC  system  is  the  LFC 
control  mode.  It  has  the  following  states: 

° LFC  On 
° LFC  Off 
° Open  Loop 


In  the  Open  Loop  State,  all  of  the  LFC  functions  are 
performed  except  the  actual  pulse  transmission  to  the 
generators.  This  mode  is  used  to  verify  the  AGC  system 
actions  as  each  new  generator  is  put  under  AGC  control. 


In  the  LFC  Off  State,  LFC  and  its  functions,  as  well  as 
interchange  scheduling  functions,  are  inoperative.  These 
latter  subsystems  require  LFC  to  carry  out  their  respec- 
tive functions. 

The  LFC  On  State  is  the  normal  state  used.  When  the  LFC 
On  State  is  selected,  LFC  can  be  used  to  automatically 
perform  its  various  functions.  The  EDC  and  Interchange 
Scheduling  Subsystems  can  also  accomplish  their  function. 

The  next  most  important  mode  is  the  ACE  calculation  moue. 
It  has  the  following  states: 

0 Tie  Line  Bias 
0 Flat  Frequency 
° Flat  Tie  Line 


Although  the  Flat  Frequency  and  Flat  Tie  Line  states 
may  be  selected,  the  state  most  frequently  used  for  this 
mode  is  the  Tie  Line  Bias  method  of  ACE  calculation. 

The  ACE  level  mode  has  the  following  states: 

° Normal  EDC 
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Permissive  EDC 
Assist 

Each  of  these  states  is  entered  automatically  by  the 
LFC  Subsystem.  An  alarm  indicating  the  status  change 
is  given  and  must  be  acknowledged  by  the  AGC  operator. 
Although  the  AGC  operator  cannot  select  any  of  the  states 
in  the  ACE  level  mode,  he  can  influence  their  selection 
by  using  CRT  to  enter  the  ACE  error  level  that  must  be 
achieved  before  a state  transition  is  made.  The  states 
are  listed  above, in  increasing  levels  of  ACE  error. 

In  the  Normal  EDC  State,  all  generators  are  moved  by  the 
LFC  Subsystem, to  the  most  economic  operating  point  com- 
puted by  the  EDC  Subsystem.  In  Permissibe  EDC,  only 
those  generators  whose  change  in  output  helps  reduce  the 
ACE  level,  are  moved  to  the  most  economical  operating 
point.  In  the  Assist  State,  the  LFC  System  attempts 
to  correct  ACE  error  while  completely  disregarding  the 
EDC  operating  point  data. 

The  Schedule  Change  Mode  is  used  to  indicate  whether  a 
schedule  change  is  in  progress.  Three  states  are  pos- 
sible : 


° Schedule  Change  Completed 
° Schedule  Change  in  Progress 
0 Schedule  Change  Desired 

The  Schedule  Change  Completed  State  is  most  frequently 
used.  When  a schedule  change  is  needed,  the  Schedule 
Change  Desired  State  is  entered.  The  state  is  main- 
tained until  LFC  starts  making  the  schedule  change. 

Then  the  Schedule  Change  in  Progress  State  is  entered. 
Upon  completion  of  the  schedule  change,  the  Schedule 
Change  Completed  State  is  re-entered. 

The  Time  Correction  Status  is  used  to  indicate  whether 
the  time  correction  relationships  are  in  use.  These 
states  are  possible: 

° Time  Correction  Completed 
° Time  Correction  in  Progress 
° Time  Correction  Desired 

Most  of  the  time,  the  LFC  Subsystem  is  operated  in  the 
Time  Correction  Completed  State.  When  a time  correction 
is  required,  the  AGC  operator  uses  the  CRT  to  enter  the 
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desired  frequency  offset  and  the  start  and  stop  times 
for  the  correction.  When  the  LFC  starts  making  the 
time  correction,  the  Time  Correction  in  Progress  State 
is  entered.  When  the  time  correction  is  completed,  the 
Time  Correction  Completed  State  is  entered  and  displayed. 

The  Economic  Dispatch  Mode  is  used  to  indicate  which  type 
of  economic  dispatch  is  wanted.  Three  states  are  pos- 
sible : 


° EDC  On 
0 EDC  Off 

° Immediate  EDC  Execution 

The  most  frequently  used  state  is  the  EDC  On  State. 

Using  this  state  the  EDC  Subsystem  automatically  cal- 
culates the  base  point  and  percent  participation  factor 
information.  If  the  EDC  Off  State  is  selected,  this 
data  must  be  entered  manually  using  the  CRT.  The  Imme- 
diate EDC  Execution  State  is  used  by  the  AGC  operator 
to  get  the  EDC  Subsystem  executing  as  soon  as  possible. 

The  Penalty  Factor  Mode  is  used  to  select  the  type  of 
penalty  factor  calculation  that  is  desired.  Three 
choices  are  possible: 

° Unity  Penalty  Factor 
° Constant  Penalty  Factor 
° Calculated  Penalty  Factor 

The  Spinning  Reserve  Mode  is  usually  specially  designed 
for  each  customer. 

The  LFC  Data  Base  Mode  has  the  following  three  states: 

° Normal 
° Hot  Start 
0 Cold  Start 

To  start  up  the  AGC  System,  the  Cold  Start  State  is 
selected.  In  this  case  the  working  AGC  Bata  Piles  are 
created  from  stored  values  on  the  disk.  In  normal 
operation  of  the  AGC  System,  the  Normal  State  is  selected. 
If  LFC  is  turned  off  for  a short  period  of  time,  the 
operator  may  choose  the  Hot  Start  State.  In  this  state, 
the  LFC  Subsystem  creates  an  updated  set  of  smoothed 
scanned  values  and  then  makes  a transition  to  the  Normal 
State . 
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In  addition  to  the  nine  modes  used  for  control  of  the 
AGC  System,  two  additional  modes  are  used  in  conjunction 
with  the  generators  and  tie  lines.  The  Generator  Control 
Mode  indicates  the  state  of  each  of  the  LFC  controllable 
generators  in  the  area.  It  has  five  states: 

° Off 
° Manual 
° LFC  Only 

° EDC  Only 

° LFC  and  EDC 

In  the  Off  State,  the  generator  output  power  is  not 
automatically  included  in  the  LFC  calculations.  In  the 
Manual  State,  the  generator  output  is  automatically 
included  in  the  LFC  calculations,  but  no  raise  or  lower 
pulses  are  calculated  or  transmitted  to  the  generator. 

The  LFC  Only  and  the  EDC  Only  States  are  used  when  a 

generator  is  used  in  that  restricted  mode  of  operation 

respectively.  In  the  LFC  and  EDC  State,  the  generator 
output  and  the  EDC  information  is  automatically  included 
in  the  LFC  calculations  and  the  appropriate  raise  or 
lower  pulses  are  calculated  and  transmitted.  There  is 
no  most  likely  state  for  a generator  to  be  in.  All  day 
long  the  generator  states  will  be  changed  to  one  of  the 
five  permitted,  in  order  to  adjust  generation  to  changing 
loads . 

When  the  EDC  Subsystem  is  in  the  EDC  Off  S-tate,  the  AGC 
Operator  must  enter  base  points  and  percent  participation 
factors  for  each  of  the  generating  units.  It  is  when 
EDC  Off  is  used  that  the  Base  Load  Regulation  and  Base 
Loaded  (generator  Unit  States  are  achieved. 

The  Tie  Line  Scan  Status  is  used  to  indicate  the  state 
of  each  of  the  tie  lines  in  the  area.  Two  states  are 
possible : 

° On 
° Off 

In  the  On  State,  the  tie  line  power  is  automatically 
scanned  and  smoothed  by  the  LFC  Subsystem.  This  is  the 
normal  state  for  a tie  line  to  be  in.  In  the  Off  State, 
usually  selected  when  there  is  a channel  communication 
failure,  the  tie  line  power  is  no  longer  automatically 
scanned.  If  the  tie  line  is  actually  carrying  power, 
the  AGC  Operator  must  add  this  tie  line  power  value  to 
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the  unmetered  tie  line  power,  and  deposit  the  result 
in  the  LFC  Data  File  using  SEMS . 

h . General  Subsystem  Information 

( 1 ) Principal  Inputs  and  Outputs 

Of  the  variety  of  information  needed  by  the  AGC 
System,  there  are  a number  of  principal  input  and 
output  quantities.  Input  quantities  include: 

° Tie  Line  Power 
0 Generator  Unit  Power 
0 Frequency  Deviation 
° Schedule  Change  Information 

The  principal  outputs  include: 

° Area  Control  Error  (for  control  and  display) 
0 Generator  Raise,  or 

° Lower  Pulses  (for  control  and  display) 

( 2 ) AGC  Alarms 

All  of  the  alarms  given  by  the  AGC  System  are  of 
the  information  type.  That  is,  they  are  given 
when  a specific  condition  is  detected  during  the 
AGC  Operation.  However,  two  of  the  LFC  alarms 
are  for  such  extreme  conditions  that  they  turn  off 
the  LFC  Subsystem. 

In  most  instances,  it  is  up  to  the  AGC  Operator  to 
interpret  the  alarm  and  its  cause, and  to  take 
appropriate  remedial  action.  The  AGC  Operator  must 
also  acknowledge  each  of  the  AGC  alarms. 

(3 ) Internal  Interfacing 

The  core  resident  AGC  Data  File  serves  as  the  main 
communication  mechanism  among  the  subsystems  in  the 
AGC  System.  Both  the  EDC  and  Interchange  Scheduling 
Subsystems  utilize  data  in  the  AGC  Data  File.  The 
results  of  the  calculations  of  these  two  subsystems 
are  communicated  to  the  LFC  Subsystem  through  the 
AGC  Data  File. 

2 . Economic  Dispatch  Calculation  (EDC)  Monitor 

The  EDC  Monitor  Program  is  a special  purpose  program  of  the 
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generalized  AGC/EDC  Solution  routine  which  forms  the  basis 
of  the  Automatic  Dispatch  EDC . Used  as  a dispatcher  aid, 
it  monitors  real-time  system  load  conditions  and  provides 
recommendations  to  the  dispatcher,  via  system  displays,  for 
loading  of  units  which  are  not  automatically  dispatched. 

These  units  are  normally  fixed-base  loaded, or  not  equipped 
for  automatic  control.  The  dispatcher  is  provided  with 
full  control  over  which  units  are  economically  monitored. 

In  this  way,  units  that  are  constrained  to  specified  levels 
of  loading  are  not  included  in  the  dispatch,  and  will  not 
influence  the  loading  of  monitored  units. 

In  use,  the  dispatcher  can  periodically  review  the  relative 
loading  of  all  units  available  to  him, and  institute  manual 
rebalancing,  resulting  in  better  economic  operation.  This 
program  can  enhance  the  effectiveness  of  automatic  economic 
dispatching  through  the  AGC/EDC  Programs,  by  providing  data 
for  the  dispatcher  to  enable  him  to  economically  dispatch 
the  off-control  and  fixed-base  generators. 

The  EDC  Monitor  Program  begins  by  determining  which  generators 
are  to  be  included  in  the  Economic  Dispatch  Solution, for  the 
determination  of  desired  generations.  The  dispatcher,  through 
CRT  entries,  can  include  or  exclude  generators  from  the  EDC 
Monitor  Solution.  All  other  generators  are  dispatched  to 
the  values  they  are  to  attain  after  any  of  the  off-control 
or  fixed-base  generators  are  directed  to  their  new  base  points 

The  EDC  Solution  Routine  is  then  executed  to  determine  the 
Desired  Generation  values  of  the  generators  included  in  the 
EDC  Monitor  Program.  The  EDC  Solution  Routine  is  solved  for 
the  case  of  Total  Gross  Generation  Required, being  equal  to 
the  current  Actual  System  Total  Gross  Generation.  All  other 
input  data,  such  as  System  Regulating  Margin  Required, 
Generator  Limits,  Tie  Line  Flows,  etc.,  is  taken  from  the 
current  real-time  system  data  base. 

The  final  processing  associated  with  the  EDC  Monitor  Program 
is  to  calculate  system  production  costs  based  on  the  current 
actual  generations.  An  alarm  message  to  the  dispatcher  is 
initiated  if  a significant  improvement  in  current  production 
cost  is  possible. 

The  EDC  Monitor  Program  results  are  stored  into  the  system 
data  base  for  subsequent  use  in  CRT  Displays. 

3 . Economics  Dispatch  Calculations  (EDC)  Study 

The  EDC  Study  Program  is  a special-purpose  embodiment  of  the 
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generalized  EDC  Solution  Routine  for  performing  special-case 
economic  studies.  Unlike  the  EDC  Monitor  Program,  which 
uses  real-time  data  in  the  monitor  mode,  the  EDC  Study  Pro- 
gram operates  with  user  specified  data  under  the  direction 
of  the  user. 

The  EDC  Study  Program  can  be  utilized  in  some  systems  as  an 
Operations  Planning  Aid.  Members  of  the  Operations  Planning 
Staff  might  use  the  program  in  conjunction  with  their  re- 
sponsibilities for  developing  plans  for  short-term  future 
operations.  The  power  dispatcher  might  utilize  the  EDC 
Study  program  to  evaluate  an  immediate  proposed  change  of 
generator  operating  conditions  or  to  evaluate  the  performance 
of  a newly  installed  generator. 

In  addition  to  the  operational  uses  of  the  EDC  Study  Program, 
the  engineering  staff  can  utilize  the  program  to  evaluate 
the  effect  of  system  data  modifications  (data  compiler 
entries)  on  the  EDC  Program  Solutions.  For  example,  the 
data  used  to  describe  a new  system  generator  could  be  added 
to  the  computer  system  and  evaluated  by  use  of  the  EDC  Study 
Program  to  ensure  the  validity  of  the  generator  data.  In 
addition,  new  B matrix  loss  coefficients  can  also  be  evaluated 
before  use  in  the  real-time  system. 

The  EDC  Study  Program  is  manually  initiated  and  the  user 
(dispatcher  or  operator)  is  allowed  full  control  to  either 
accept  or  modify  the  data  inputs  (System  Load,  System  Inter- 
change, Regulating  Margin  Required,  Generator  Status,  Gen- 
erator Limits,  etc.). 

The  Study  Data  Base  Initialization  Logic  shares  the  initial- 
ization processing  characteristics  of  other  study  programs. 

The  study  data  base  is  initialized  to  a judicious  combination 
of  current  (real  time)  and  forecast  (Load  Forecast,  Inter- 
change Schedule)  conditions, in  a manner  which  provides  all 
data  required  for  the  study  solution,  with  the  minimum 
necessary  amount  of  user  entries. 

The  EDC  Study  Program  results  are  available  to  the  user  via 
the  CRT  Displays,  or  optionally,  the  user  may  choose  to 
direct  the  study  program  results  to  the  system  printer.  The 
data  results  are  available  until  such  time  as  the  study 
program  is  terminated. 

4.  Transaction  Management  Package 

The  Transaction  Management  Package  consists  of  a design 
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coordinated  set  of  five  programs  which  support  all  functions 
associated  with  the  evaluation,  scheduling,  and  accounting 
of  interchange  schedules.  They  are  interfaced  with  standard 
data  acquisition,  data  base,  and  man-machine  software  sub- 
systems. Programs  execute  periodically  or  on  demand  by 
the  dispatcher.  All  operator  interface  with  these  programs 
is  through  appropriately  defined  CRT  Displays.  The  focal 
point  of  these  programs  is  the  Transaction  Inventory  Files. 
These  data  files  are  maintained  in  bulk  memory,  and  contain 
all  data  pertinent  to  past,  pending,  and  future  Scheduled 
Interchange  Transactions. 

Interchange  schedules  are  entered  by  the  dispatcher  through 
the  Interchange  Transaction  Scheduler  Program.  This  program 
maintains  an  inventory  of  all  transactions  until  they  are 
canceled  or  completed,  and  processed.  It  also  determines 
the  scheduled  net  interchange,  and  implements  schedule  changes 
through  the  Automatic  Generation  Control  Program. 

The  actual  production  costs  associated  with  each  ongoing 
transaction  are  computed  periodically  by  the  Transaction 
Reconstruction  Monitor  Program.  This  program  calculates  the 
average  cost  of  each  active  transaction  using  data  from  the 
EDC  Solution  Routine.  The  data  resulting  from  these  cal- 
culations is  stored  in  the  cost  reconstruction  data  files 
which  are  part  of  the  Transaction  Inventory. 

Periodically,  each  hour,  the  Transaction  Accounting  Monitor 
Program  processes  the  data  associated  with  transactions 
completed  during  the  last  hour.  This  includes  actual  kWh 
data  acquired  by  the  data  acquisition  function.  This  data 
is  combined  with  other  pertinent  data  stored  for  each  trans- 
action in  the  Transaction  Inventory  Files.  This  processed 
data  is  stored  on  a daily  basis  in  the  Completed  Transaction 
Files.  This  information  can  be  printed  in  summary  form  for 
each  day's  operation, for  use  in  billing  operations.  In 
addition  to  this  billing  data,  historical  records  are  also 
constructed  in  the  form  of  daily  files  of  hourly  cost  data 
by  transaction.  These  files  can  be  maintained  on  bulk 
memory,  dumped  through  the  system  printer,  card  punch, or 
magnetic  tape,  or  reloaded  for  updates  using  manually  entered 
corrected  data. 

Potential  interchange  transactions  can  be  evaluated  through 
two  additional  programs:  Economy  A Evaluation  and  Economy  B 
Evaluation.  These  programs  make  use  of  two  additional 
standard  application  programs:  EDC  Solution  Routine  and 
Dynamic  Generation  Scheduling  Program. 
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The  Economy  A Evaluation  Program  is  for  use  in  evaluating 
the  cost  or  savings  associated  with  transactions  to  be 
implemented  during  the  next  few  hours.  This  program  com- 
bines the  potential  transaction  with  existing  real-time 
system  conditions  to  perform  the  evaluation.  The  EDC 
Solution  Routine  is  used  to  determine  the  operating  cost 
under  the  specified  conditions.  Minor  changes  in  existing 
operating  conditions  can  be  made  by  alteration  of  the  real- 
time base  case  data. 

The  Economy  B Evaluation  Program  is  designed  for  use  in 
evaluating  transactions  for  operating  conditions  that  differ 
greatly  from  real-time  conditions.  This  study  may  be  in 
support  of  a future  transaction,  or  may  be  for  evaluation  of 
a "dedicated  unit"  type  transaction.  This  program  utilizes 
the  Unit  Commitment  program  to  determine  the  proper  scheduling 
of  units  for  use  in  the  study.  Operating  costs  for  the 
transactions  being  studied  are  computed  by  the  EDC  Solution 
Routine  as  done  with  the  Economy  A Evaluation  Program. 

The  results  of  these  study  programs  are  reviewed  by  the 
dispatcher, and  the  desired  transactions  can  then  be  scheduled 
through  the  Interchange  Transaction  Scheduler. 

5 . Interchange  Transaction  Scheduler 

The  Interchange  Transaction  Scheduler  (ITS)  program  manages 
information  regarding  each  scheduled  transaction  with  non- 
associated  interconnected  companies  or  agencies.  This 
information  includes  agency  identification,  type  of  inter- 
change, associated  costs  and  price  quotations,  magnitude 
and  direction  of  the  interchange,  start  time,  ramp  rate, 
and  duration  of  the  interchange  transaction.  Each  scheduled 
transaction  is  assigned  a ledger  number  for  identification 
and  filing  in  the  transaction  inventory.  Based  on  this 
data,  an  inventory  of  interchange  schedules  is  formed  to 
store  individual  schedules  in  an  organized  manner.  The 
schedule  control  processor  computes  the  total  net  scheduled 
interchange  for  use  by  the  Automatic  Generation  Control 
program.  It  also  provides  interchange  schedule  data  for 
the  Transaction  Accounting  Monitor  program. 

ITS  consists  of  a number  of  processors  and  specialized  data 
handling  routines  which  service  a central  data  base  called 
the  Inventory  of  Scheduled  Transactions.  It  also  provides 
an  interface  with  other  subsystems  and  other  application 
programs . 
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An  ITS  Software  Handler  coordinates  the  execution  of  the 
various  program  processors,  It  determines  the  purpose 
of  the  program  call  and  transfers  control  to  the  proper 
processors.  The  Initialization  module  is  used  only  during 
system  startup  to  initialize  program  functions.  Depending 
on  the  source  of  the  program  call,  the  ITS  Software  Handler 
passes  control  to  either  the  ITS  Input  Processor,  the  ITS 
Display  Processor,  or  the  Scheduling  Coordinator. 

Transaction  schedules  are  made  through  the  CRT  operator's 
console,  using  the  ITS  Input  Processor.  Specialized  routines 
are  used  to  insert  or  delete  individual  schedules  to/from 
the  inventory.  The  ITS  Output  Processor  provides  display 
data  for  the  operator's  CRT.  This  allows  operator  entry 
of  transaction  pricing  data  as  it  is  established.  Each 
schedule  is  assigned  a unique  ledger  number  for  filing 
within  the  inventory.  Provisions  are  provided  to  store 
multiple  transactions  per  agency.  Each  schedule  entry  is 
checked  for  legality,  based  on  established  scheduling  rules. 
For  example,  the  attempt  to  enter  an  Economy  A Transaction 
with  an  agency  currently  scheduled  to  receive  an  Emergency 
Interchange,  may  result  in  an  operator  alarm. 

A Scheduling  Coordinator  routine  provides  coordination  of 
all  schedules  entered  into  the  Transaction  Inventory.  It 
uses  threaded  list  techniques  to  link  schedules.  The 
entered  start  and  stop  times  for  each  transaction  are  used 
in  the  threading  to  determine  the  next  schedule  change  to 
be  performed.  This  routine  schedules  the  ITS  Program  with 
the  system  executive  using  the  "callback"  technique  to 
perform  schedule  changes  at  the  required  time.  This  routine 
also  maintains  the  status  of  each  transaction  by  flagging 
it  as  pending,  active,  completed  or  deleted.  When  schedule 
changes  are  required,  the  Scheduling  Coordinator  will  pass 
control  to  the  Schedule  Control  Processor.  Completed 
schedules  will  be  flagged  to  identify  them  for  processing 
by  the  Transaction  Energy  Accounting  Program.  This  program 
will  construct  historical  files  and  generate  reports  giving 
energy  and  cost  data  on  scheduled  power  exchange  on  a daily 
basis . 

The  Schedule  Control  Processor  combines  the  scheduled  trans- 
action change  with  the  current  Interchange  Scheduler  and 
passes  this  value  along  with  the  transaction  ramping  rate 
to  the  AGC  Program  for  implementation. 

The  Interchange  Print  Processor  constructs  schedule  change 
messages  for  logging  on  the  system's  events  or  alarm  printer. 
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These  messages  give  the  time,  agency,  type,  and  amount  of 
each  schedule  transaction. 

The  Transaction  Inventory  contains  all  data  related  to  an 
individual  transaction,  pending  or  completed.  Start  and 
stop  times  for  schedules  are  specified  by  the  year,  day, 
hour,  and  minute  to  permit  scheduling  of  future  transactions. 
The  total  number  of  schedules  in  the  inventory  is  limited 
by  the  storage  provisions  allowed  for  each  agency.  Data 
consistency  checks  are  performed  for  each  transaction  entry 
and  alarms  are  produced  for  error  conditions.  Also,  the 
type  of  transaction  (economy,  emergency,  payback,  etc.)  is 
also  maintained  in  the  inventory.  Transactions  may  be 
scheduled  up  to  one  year  in  advance  of  the  transaction. 

Price  quotations  by  the  utility  and  the  transaction  agency 
are  also  stored  in  the  inventory.  On  an  optional  basis, 
reconstruction  cost  data  computed  by  the  Cost  Reconstruction 
Monitor  Program  may  also  be  entered  into  the  inventory. 

The  Inventory  of  Scheduled  Transactions  may  be  accessed  by 
the  Transaction  Accounting  Monitor,  the  System  Load  Forecast 
Program,  the  Economy  A Transaction  Program,  or  other  study 
type  programs  which  require  a future  projected  load  value. 

6 . Transaction  Accounting  Monitor 


The  Transaction  Accounting  Monitor  (TAM)  collects  data  related 
to  the  cost  accounting  required  for  all  interchange  trans- 
actions. This  data  is  maintained  in  coordinated  historical 
files.  It  is  also  printed  in  a daily  report  for  use  in  off- 
line billing  procedures.  Transaction  accounting  data  is 
taken  from  the  inventory  of  transactions  maintained  by  the 
Interchange  Transaction  Scheduler  Program.  This  data  is  also 
used  to  compute  the  inadvertent  interchange  data  acquisition 
system.  Files  are  maintained  and  updated  for  each  hour  of 
operation.  Provisions  are  also  made  for  entry  of  after-the- 
fact  pricing  data. 

TAM  is  concerned  with  observation  of  two  classes  of  data: 
interchange  energy  data  and  completed  transaction  data.  This 
data  is  processed  and  accumulated  into  files  for  reports  and 
off-line  processing.  The  program  is  modular,  consisting  of 
a number  of  processors  which  construct  these  files  and 
reports.  The  program  is  scheduled  for  execution  after  the 
hourly  kWh  data  scan  and  Cost  Reconstruction  Monitor  (if 
present)  calculations  have  been  completed. 

The  program's  Interchange  Energy  Processor  constructs  hourly 
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files  of  scheduled  and  actual  interconnected  tie  energy 
flow  on  a system-wide  basis,  and  computes  inadvertent 
interchange.  Actual  kWh  energy  flow  for  each  tie  line  is 
obtained  from  the  kWh  scan  data  collected  hourly  by  the 
data  acquisition  subsystem.  The  net  schedule  interchange 
is  obtained  from  the  Interchange  Transaction  Scheduler 
Program  through  the  Transaction  Inventory  Files.  This  data 
is  used  to  determine  the  inadvertent  interchange 
accumulated  during  the  hour.  Provisions  are  made  to 
determine  on  and  off  peak  accumulation  of  inadvertent 
interchange  over  a 2U-hour  period.  This  data  can  be  report- 
ed as  required  through  events  logging,  accumulated . in  the 
bulk  memory  files,  and  reported  on  a daily  basis.  This 
data  can  also  be  displayed  through  a CRT  Msplay  for 
manual  updates  by  the  system  dispatcher,  based  on  manual 
readings  or  negotiated  final  transaction  costs. 

The  tie  line  energy  data  file  typically  contains  the 
following  hourly  data: 

0 KWh  actual  energy  for  interconnection  tie  lines 

° Net  interchange  MWh  accumulation  for  the  hour 

° Scheduled  net  interchange  for  the  hour 

° Inadvertent  interchange  for  the  hour 

° Accumulated  on  and  off  peak  inadvertent  inter- 
change for  the  day  (up  to  the  current  hour) 

These  files  are  identified  by  the  date  on  which  they 
were  created. 

A Completed  Transaction  Processor  interfaces  with  the 
Transaction  Inventory  to  process  transactions  completed 
during  the  past  hour.  This  processor  computes  the  total 
scheduled  MWh  for  each  transaction.  All  data  associated 
with  a completed  transaction  is  removed  from  the  Trans- 
action Inventory  and  that  transaction's  status  is 
changed  to  indicate  that  the  transaction  is  deleted.  This 
procedure  allows  the  Interchange  Transaction  Scheduler  to 
utilize  that  file  entry  for  a new  future  transaction. 

The  completed  transaction  file  typically  contains  the 
following  data  for  each  transaction: 

° Transaction  Inventory  ledger  number 
° Identification  of  non-associated  interconnected 
agency 
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Type  of  transaction 
° Magnitude  and  direction  of  interchange 
° Start  time,  date,  year 
° Stop  time,  date,  year 

° Utility  price  quotation,  agency  price  quotation 
° Reconstruction  cost  with  and  without  each  trans- 
action (included  only  if  the  application  requires 
the  Cost  Reconstruction  Monitor  Program) 

These  files  are  of  fixed  length  and  are  identified  by  the 
date  on  which  they  were  created. 

An  Historical  File  Builder  takes  the  tie  line  energy  data 
and  the  completed  transaction  data,  and  enters  it  into  the 
daily  transaction  files  maintained  in  bulk  memory.  Up 
to  N(N  is  typically  4 to  7 ) daily  files  are  maintained  in 
bulk  memory.  This  allows  after-the-fact  updates  to  the 
transaction  and  tie  line  data, by  the  system  dispatcher, 
to  accommodate  agreements  reached  on  pricing  or  adjust- 
ment to  computed  cost  data.  These  storage  provisions 
also  accommodate  weekends  and  holidays  when  final  action 
on  completed  transactions  may  be  deferred. 

An  Historical  File  Display  and.  Update  Processor  allows  for 
selective  display  on  the  CRT  of  tie  line  and  transaction 
data  stored  in  a particular  daily  file.  This  allows 
operator  entry  of  updates  or  corrected  data  to  these  files 
This  is  especially  helpful  for  the  cases  already  mentioned 
in  relation  to  after-the-fact  transaction  pricing. 

The  TAM  program  is  interfaced  to  the  generalized  system 
Information  Storage  and  Retrieval  Software,  which  allows 
for  removal  of  daily  files  from  bulk,  memory.  This  can  be 
performed  in  a number  of  ways,  .such  as  printed  reports, 
punched  cards,  or  magnetic  tape,  as  required  by  the 
application.  This  is  usually  influenced  by  the  analysis, 
accounting,  or  billing  procedures  which  utilize  these  files 
The  actual  method  used  is  dependent  upon  the  overall  oper- 
ating procedures  required  for  a particular  application. 

7 . Transaction  Reconstruction  Monitor 

The  Transaction  Reconstruction  Monitor  (TRM)  collects 
data  related  to  the  cost  or  savings  associated  with 
active  interchange  transactions.  This  data  is  used  to 
evaluate  the  effectiveness  of  prenegotiated  economy 
transactions , to  determine  the  cost  efficiency  of 
transactions,  and  for  after-the-fact  price  determination 
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of  completed  transactions  (Economy  A,  for  example).  Sav-; 
ings  are  estimated  through  the  use  of  the  EDC  Solution 
Routine  calculation.  The  scheduled  net  interchange  is 
modified  for  each  transaction  in  turn, to  represent  its 
effect  on  system  load.  Scheduled  transactions  are  removed, 
based  on  a priority  sequence  established  by  the  utility's 
operating  policy.  Results  of  the  reconstruction  cal- 
culations are  structured  into  hourly  files  in  bulk  memory. 

Provisions  are  made  to  manually  update  these  files  and  to 
dump  them  for  off-line  processing. 

TRM  is  one  of  the  optional  programs  in  the  Transaction 
Management  Package.  It  interacts  with  the  inventory  of 
scheduled  transactions  maintained  by  the  Interchange 
Transaction  Scheduler.  It  stores  average  production  cost 
data  into  that  file  for  later  processing  by  the  Transaction 
Accounting  Monitor. 

TRM  produces  two  classes  of  data.  One  is  the  average 
production  cost  data, which  is  calculated  during  the  hour 
for  each  active  transaction.  This  data  is  stored  into 
the  transaction  inventory.  The  other  class  of  data  con- 
sists of  hourly  production  cost  data  for  individual  units 
and  transactions.  These  files  are  constructed  by  TRM  and 
maintained  in  bulk  memory.  This  data  can  be  dumped  under 
operator  direction  for  off-line  processing.  The  program 
is  executed  periodically  (typically  every  5-10  minutes) 
and  updates  the  historical  transaction  cost  files  at  the 
end  of  each  hour. 

TRM  is  made  up  of  functional  modules,  each  designed  to 
perform  one  step  in  the  reconstruction  calculation  and 
management  of  the  resulting  historical  files.  The 
first  step  in  the  reconstruction  cost  calculation 
consists  of  establishing  the  base  case  data  for  the 
Economic  Dispatch  Calculation.  This  is  done  by  an  EDC 
Base  Case  Preprocessor.  Real-time  data  from  the  system 
data  base,  consisting  of  unit  status  and  generation 
data,  is  captured  and  placed  in  the  base  case  files. 

This  procedure  is  also  followed  for  the  current  parameters 
(fuel  cost,  incremental  heat  rates,  loss  data)  used  by 
the  real-time  EDC.  By  transferring  this  data  into  a study 
data  base,  the  effects  of  real-time  data  gathering  and 
data  entries  are  blocked  from  affecting  the  reconstruction 
calculations . 
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The  next  module  in  the  execution  of  the  program  is  the 
Reconstruction  Sequence  Logic  which  interrogates  the  ITS 
Transaction  Inventory  to  obtain  data  which  identifies  all 
currently  active  transactions.  A priority  is  assigned  to 
each  active  transaction  based  on  its  type,  duration,  etc., 
as  dictated  by  utility  operating  practice.  This  priority 
determined  the  sequence  in  which  schedules  are  removed 
from  the  system  in  computing  reconstruction  cost.  An 
example  of  this  sequence  would  be  to  remove  all  emer- 
gency transactions  followed  by  all  Economy  A transactions. 
Transactions  of  the  same  type  may  be  ranked  on  the  basis 
of  the  sequence  in  which  they  were  negotiated. 

Reconstruction  calculations  are  controlled  by  the  Recon- 
struction Loop  Module,  which  removes  each  transaction  in 
turn.  This  is  done  by  reducing  total  system  load  to  be 
dispatched  by  the  amount  of  the  transaction  under  eval- 
uation. Each  time  the  scheduled  net  interchange  is 
changed,  tie  line  distribution  factors  are  used  to 
determine  the  associated  flow  on  the  system  tie  lines.  The 
resulting  data,  along  with  the  Base  Case  File  Data 
established  earlier,  is  then  used  in  the  EDC  Solution 
Routine.  The  resulting  desired  generation  values  are 
used  to  compute  corresponding  production  costs  for  each 
generation  source,  and  for  the  system  as  a whole.  The 
resulting  data  is  stored  in  an  Inter-Hour  Production 
Cost  Data  File.  This  calculation  sequence  is  repeated  for 
each  currently  active  interchange  transaction. 

The  Hourly  Averaging  Routine  is  scheduled  for  execution 
at  the  end  of  each  hour.  This  routine  takes  data  from  the 
Inter-Hour  Production  Cost  Data  File,  and  calculates  aver- 
age production  cost  for  the  hour,  for  each  active  or 
currently  active  transaction.  The  resulting  data  is 
stored  with  mother  transaction  data  in  the  Transaction 
Inventory.  For  ongoing  transactions,  each  hour's 
average  production  cost  is  combined  with  the  duration 
of  the  transaction  expressed  in  hours. 

Another  routine  that  is  scheduled  for  execution  at  the  end 
of  each  hour,  is  the  Historical  File  Builder.  This  module 
constructs  files  containing  detailed  cost  data  for  each 
active  transaction  for  each  hour  it  is  active.  These 
files  are  constructed  for  each  day  and  are  identified  by 
the  transaction  ledger  number. 
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The  files  typically  contain  the  following  data  for  each 
transaction  for  each  hour  it  is  active: 

0 Hour  of  the  day 

0 Transaction  Inventory  ledger  number 

° Identification  of  non-associated  interconnection 
agency 

° Type  of  transaction 

° Incremental  production  cost  of  each  generation 
source 

° Incremental  maintenance  cost  of  each  generation 
source 

° Incremental  system  losses  resulting  from  the 
transaction 

Up  to  N (N  is  typically  4 to  7)  daily  files  are  maintained 
in  bulk  memory.  This  allows  after-the-fact  updates  to  the 
transaction  production  cost  data, by  the  system  dispatcher, 
to  accommodate  changes  in  the  real-time  system.  These 
storage  provisions  also  accommodate  weekends  and  holidays, 
when  final  action  on  completed  daily  files  may  be  deferred. 

An  Historical  File  Display  and  Update  Processor  allows  for 
selective  display  on  the  CRT  Console  of  reconstruction 
data  stored  in  a particular  daily  file.  Updates  to  these 
files  may  be  made  through  these  displays. 

This  program  is  interfaced  to  the  generalized  system 
Information  Storage  and  Retrieval  Software,  which  allows 
for  removal  of  these  files  from  bulk  memory.  This  can  be 
performed  in  a number  of  ways,  such  as  printed  reports, 
punched  cards,  or  magnetic  tape,  as  required  by  the 
application.  This  is  usually  dependent  on  the  analysis, 
accounting  or  billing  procedures  which  utilize  these  files. 
The  actual  method  used  is  dependent  upon  the  overall  oper- 
ating procedures  required  by  a particular  application. 

8.  Economy  A Transaction  Evaluation 

This  program  performs  a production  cost  evaluation  to 
establish  the  cost  or  savings  resulting  from  an  economy 
energy  transaction  with  a neighboring  agency.  Economy 
A Transactions  are  typically  made  on  a short-term  basis 
based  on  committed  units,  and  utilizing  spinning  reserve. 
They  are  cancellable  either  by  transaction  agency,  or 
renewed  on  an  hour-by-hour  basis.  Typically,  pricing  is 
established  on  a split -the- savings  basis.  This  program 
is  one  of  the  optional  programs  in  the  design  coordinated 
Transaction  Management  Package. 
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The  evaluation  is  initiated  by  the  system  dispatcher  on  a 
demand  basis.  A CRT  Display  is  used  to  enter  the  hour  to 
be  studied,  the  estimated  system  load,  planned  changes 
in  unit  commitment,  the  transaction  amount,  and  the 
increments  to  be  studied.  Each  transaction  increment 
results  in  a full  pass  through  the  calculations.  Initially, 
a base  case  calculation  is  performed  to  establish  base 
operating  cost  for  expdcted  system  load  and  previously 
scheduled  transactions. 

The  basis  of  the  Economy  A Transaction  Evaluation  (ITAE) 
id  the  EDC  Solution  Routine,  separate  f ran, but  similar  to 
the  real-time  economic  dispatch.  This  includes  a Full  15- 
Matrix  Loss  Calculation  and  a desired  Generation  Calcula- 
tion. The  resulting  desired  generation  values  are  then 
used  to  calculate  production  costs  and  other  Economy  A 
calculations.  Based  on  the  results  of  the  evaluation, 
acceptable  schedule  data  can  be  directly  entered  into  the 
Interchange  Transaction  Scheduler  program. 

ITAE  consists  of  a number  of  processors  and  specialized 
data  handling  routines  which  create  and  process  a number 
of  study  data  files.  To  initiate  an  Economy  A Study,  the 
following  data  is  entered  through  a CRT  Display: 

° Agency  being  studied 
° Hour  of  the  study 
° Expected  system  load 
° Power  exchange  to  be  evaluated 
° Transaction  increments  to  be  studied 
0 Changes  in  status  of  units  on-line 
° Tie  line  distribution  factors  to  be  used 

A Base  Case  Processor  is  used  to  retrieve  other  system 
data  required  for  the  execution  of  the  economic  dispatch 
calculation.  This  data  is  structured  into  the  Base  Case 
Data  File  to  insure  immunity  from  the  system  changes 
during  the  study  calculations.  This  data  includes: 

0 Unit  operating  status  modified  by  operator  entries 
° Unit  operating  limits 
° Unit  fuel  costs 
° Unit  incremental  heat  rate  data 
° Unit  incremental  maintenance  data 
0 Transmission  loss  constants 
0 Non-conforming  load  data 
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The  scheduled  net  interchange  that  exists  during  the  horn- 
studied  is  obtained  from  the  Transaction  Inventory 
maintained  by  the  Interchange  Transaction  Scheduler. 

A Study  Pass  Processor  controls  each  pass  or  execution  of 
the  program  for  the  increments  of  the  interchange  under 
evaluation.  The  initial  execution  path  computes 
production  costs  without  any  additional  interchange  to 
establish  base  case  values  to  be  used  as  a reference. 

Then*  each  increment  of  the  transaction  under  evaluation 
is  added  to  existing  net  interchange  and  another  pass 
is  made.  Before  each  pass  the  net  interchange  scheduled 
is  divided  among  the  interconnection  tie  line  through 
predetermined  tie  line  distribution  factors.  These  factors 
assign  the  portion  of  the  net  interchange  each  tie  line 
can  be  expected  to  carry  under  actual  operating  conditions. 
Alternate  sets  of  these  factors  may  be  used  to  better 
match  operating  conditions  that  will  be  known  to  exist,  for 
the  time  being  studied.  These  alternate  factors  will  be 
specified  as  part  of  the  study  definition.  This  allows 
a distinction  to  be  made  between  on-peak  and  off-peak 
operation  or  weekday  versus  weekend  or  holiday. 

The  basis  of  the  Economy  A Evaluation  is  the  EDC  Solution 
Routine.  At  the  conclusion  of  the  EDC  the  Economy  A 
Calculation  is  executed.  This  module  computes  the  produc- 
tion cost  data  based  on  the  desired  generations  computed 
by  the  EDC.  These  calculations  include  the  total  system 
cost,  average  cost  for  the  transaction  increment  under 
study,  and  the  weighted  average  cost  for  the  agency 
being  studied.  All  results  are  stored  in  the  Study 
Results  File. 

A CRT  Display  of  pertinent  results  is  formulated  to  allow 
the  operator  to  evaluate  the  study  results.  Based  on  the 
data  displayed,  the  dispatcher  can  negotiate  a transaction 
and  enter  the  additional  transaction  data  required.  This 
data  can  be  directly  passed  to  the  Interchange  Transaction 
Scheduler.  Alternately,  the  dispatcher  can  select  a full 
study  report  to  be  printed  on  the  system  printer.  Based 
on  this  report,  the  dispatcher  can  then  enter  the  new 
schedule  by  the  standard  procedures  provided  by  the  Inter- 
change Transaction  Scheduler. 
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9 . Economy  B Transaction  Evaluation 


This  program  performs  a production  cost  evaluation  to 
establish  the  costs  or  savings  resulting  from  an  economy 
energy  transaction  with  a neighboring  agency,  based  on 
possible  operating  conditions.  Economy  B transactions  are 
typically  made  well  in  advance  of  implementation  and 
require  commitment  of  additional  generation  resources. 
Pricing  is  typically  established  on  the  basis  of  the 
anticipated  operating  conditions  and  may  include  startup 
cost  of  additional  generating  sources.  This  program 
is  one  of  the  optional  programs  in  the  design-coordinated 
Transaction  Management  Package. 

The  basis  of  the  Economy  B Transaction  Evaluation  (ITEB) 
is  the  Rockwell  Dynamic  Generation  Scheduling  (DGS) 
program.  The  implementation  of  this  program  requires 
implementation  of  the  DGS  program.  ITEB  provides  a 
convenient  means  for  coordinating  the  use  of  DGS  for 
this  type  of  study  function.  The  DGS  is  unaffected  by 
its  use  in  an  Economy  B Transaction  Evaluation. 

The  evaluation  is  initiated  by  the  system  dispatcher  on 
a demand  basis  using  a single  Economy  B Transaction 
Evaluation  display.  The  program  is  a study  type  and 
supports  a number  of  study  cases.  Each  study  case  supports 
a single  evaluation  and  may  be  maintained  by  the  system 
until  it  is  reused  for  a new  evaluation.  To  start  the 
study,  the  dispatcher  selects  an  available  study  case 
and  enters  the  transaction  MW  increment  to  be  studied 
along  with  the  date,  hour,  and  duration  which  serves  as 
the  study  case  identification.  The  program  then  requests 
execution  of  the  DGS  program.  The  dispatcher  can  use  the 
DGS  program  input  displays  to  further  establish  input 
data  prior  to  initiating  execution  to  perform  the 
Economy  B Transaction  Evaluation. 

Following  the  first  pass  execution  of  the  DGS  program, 
control  is  returned  to  the  Economy  B Transaction  Evalua- 
tion program  along  with  the  identification  of  the 
DGS  Study  Case  which  was  used.  The  final  hourly  produc- 
tion costs  data  is  captured  from  the  DGS  Study  Case  to 
the  ITEB  Study  Case.  ITEB  then  modifies  the  DGS  Study 
Case  to  include  the  effect  of  the  additional  interchange 
to  be  evaluated  using  the  "Previous  Case"  input  option  and 
requests  a reexecution  of  the  DGS  program. 


A-33 


Following  this  second  pass  of  the  generation  scheduling 
study,  control  is  again  returned  to  ITEB.  Again  the 
hourly  production  costs  are  captured  into  the.  ITEB  Study 
Case.  The  production  cost  figures  are  then  ccmpared  and 
summarized  on  the  ITEB  Study  Case  display  for  review  by 
the  dispatcher.  Typically,  one  study  increment  is  used  for 
a study  of  this  type.  The  dispatcher  can  use  the  resulting 
hourly  production  cost  data  to  approximate  the  added  cost 
of  interchange  increments  of  varying  sizes.  Alternately, 
he  may  also  request  the  DGS  program  directly,  call  up 
the  second  pass  version  of  the  DGS  Study  Case,  and  make 
further  alterations  and  study  reruns  directly. 

. Adaptive  Load  Forecast  Study 

The  Adaptive  Load  Forecast  program  uses  a generalized 
load-weather  model  and  forecasted  weather  conditions  to 
forecast  hour  load  for  the  next  2h-30  hours  of  operation. 
The  generalized  load  model  consists  of  components 
representing  the  base  load,  the  day  of  the  week  load,  the 
weather  induced  load,  the  scheduled  non-conforming  load, 
and  the  random  load.  Multiple  load  models  can  be  defined 
for  each  distinct  load  center  or  region,  each  having 
distinct  load  or  weather  characteristics.  These  models 
would  be  custom  fit  to  the  user's  service  area  based  on 
an  engineering  analysis  of  previous  weather  and  load 
data.  The  methodolgy  makes  use  of  stepwise  linear 
regression  techniques.  The  program  maintains  load-weather 
models  on-line,  and  dynamically  adapts  these  models  to 
seasonal  changes  in  weather  and  load.  This  adaptive  proce- 
dure recognizes  the  load  growth  trend,  the  daily  load 
profile,  and  the  weather-induced  load  effect. 

In  application,  the  base  regional  load  component  and  the 
day-of-the-week  component  are  modeled  jointly.  This  is 
accomplished  by  forming  separate  hourly  models  for  each 
day  of  the  week,  thus  eliminating  the  need  to  separately 
model  each  component  and  then  combining  the  results.  The 
base  load  models  use  exponential  smoothing  techniques. 

The  weather  induced  component  of  the  load  is  modeled  by  a 
summer  model  and  a winter  model,  each  containing 
appropriately  selected  weather  variables.  While  the  pro- 
gram is  somewhat  generalized  in  its  processing  of  the  load 
components  and  load-weather  models  listed  above,  it  must 
be  tailored  to  the  user's  service  area  through  a study 
of  historical  data.  This  analysis  will  be  performed 
during  implementation  based  on  actual  utility  load  and 
weather  data. 


The  scheduled  non-conforming  load  requires  no  modeling. 
Table  look-up  procedures  are  used  to  add  into  the  load 
model  known  and  pre scheduled  non- conforming  loads. 
Likewise,  the  random  load  component  cannot  be  modeled 
since  it  represents  the  truly  random  portion  of  the  load 
which  cannot  be  forecasted.  It  can  also  be  viewed  as  fore- 
casting error. 

Selection  of  proper  weather  variables  is  a key  part  of 
this  load-weather  modeling.  For  a summer  model,  tempera- 
ture has  always  been  a key  load-related  variable  due  to 
cooling  load.  Cooling  demand  is  related  to  dry  bulb 
temperature  minus  a constant  reference  temperature  in  the 
order  of  60  to  65  degrees  F.  In  a summer  model,  cooling 
demand  may  also  be  related  to  the  difference  in  moisture 
content  of  the  air  before  and  after  dehumidification.  In 
the  summer  many  buildings  are  open  to  the  outside  and 
inside  temperature  tracks  ambient  directly  up  to  a certain 
point  where  heat  buildup  becomes  a factor.  Similarly, 
for  winter  models  the  heating  load  is  related  to  a 
constant  threshold, minus  dry  bulb  temperature.  And  while 
moisture  content  of  the  air  has  less  influence  in  the  win- 
ter model,  wind  velocity  may  greatly  affect  load  at  lower 
temperatures.  Because  buildings  tend  to  be  closed  up 
during  the  winter,  lagged  weather  variables  may  be  re- 
quired to  model  the  thermal  time  constants  or  heat  storage 
effects  of  buildings. 

Many  of  these  relationships  are  complex,  and  if  mathemat- 
ically well-behaved  linear  regression  techniques  are  to  be 
used,  suitable  weather  variable  transformations  must  be 
determined.  This  determination  is  made  from  an  analysis 
of  historical  weather  and  load  records. 

Three  programs  are  used  to  perform  the  system  load  fore- 
casting function:  Load  Forecast  Model  Update,  Forecasted 
Weather  Data,  and  System  Load  Forecast.  These  on-line 
programs  are  supported  by  a file  created  by  the  batch 
mode  Load-Weather  Parameter  File  Program. 

The  basis  for  the  load  forecast  prodedure  is  the  Daily 
Operations  File  and  the  Load-Weather  Parameter  File. 

The  Daily  Operations  File  contains  the  load  and  weather 
data.  This  data  supports  the  important  off-line  procedure 
of  model  initialization  through  the  Load- Weather  Parameter 
File  program.  This  program  uses  approximately  two  months 
of  data  to  initialize  the  parameters  of  the  model  deter- 
mined by  manual  analysis,  as  described  previously.  The 
program  allows  restarting  of  the  forecasting  model 
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initially  (system  startup)  and  whenever  required  by 
non-availabilit’  of  weather  and  load  data, or  the  use  of 
erroneous  data  ransducer  failure,  operator  entry  error, 
etc.)*  This  program  would  be  used  infrequently  and  is 
not  part  of  the  daily  load  forecast  processing.  The 
resulting  Load-Weather  Parameter  File  is  the  basic 
"memory"  required  for  the  forecasting  procedure  and 
contains  the  current  parameters  of  the  various  load 
models . 

The  Load  Forecast  Model  Update  Program  provides  the  impor- 
tant adaptive  capability  of  the  forecasting  procedure.  It 
continuously  a ipts  the  model  in  real-time  by  tracking 
load  growth,  seasonal  effects,  and  weather  patterns.  The 
rate  at  which  the  adaptation  takes  place  is  matched  to 
the  dynamics  of  the  associated  load  component.  This  elim- 
inates the  need  for  any  on-line  program  tuning.  Hie 
update  programs  execute  daily  at  midnight  to  process 
the  previous  day’s  load  and  weather  data,  as  recorded  in 
the  Daily  Operations  File.  It  can  also  be  executed  on 
demand  to  process  data  that  may  have  been  entered  manually 
to  correct  erroneous  data.  The  resulting  model  update 
data  is  stored  in  the  Load-Weather  Parameter  File. 

The  Forecasted  Weather  Data  program  processes  system 
operator  entered  data  on  demand  for  use  in  forecasting. 

The  entries  include  forecast  day,  scheduled  non-conforming 
loads,  and  forecasted  weather  variables.  This  data  is 
combined  with  any  actual  weather  data  available  from  the 
Daily  Operations  File  for  a same  day  forecast.  Weather 
data  may  be  entered  through  the  System  Load  Forecast 
Request  Display  at  three-hour  intervals,  to  match 
availability  from  the  U.S.  Weather  Bureau  stations. 

Missing  or  non-entered  data  can  be  approximated  using 
profiles  from  previous  weather  variable  patterns.  Once 
processed,  a complete  set  of  forecasted  weather  data 
is  stored  in  the  Forecasted  Weather  Data  File.  These 
daily  files  can  be  recalled  to  the  System  Load  Forecast 
Request  display  for  entry  of  additional  data  as  required. 

The  System  Load  Forecast  Program  executes  on  demand 
through  entries  made  by  the  system  operator.  This  program 
retrieves  the  current  model  data  from  the  Load-Weather 
Parameter  File  a^d  reads  the  processed  weather  data  sent 
from  the  Forecas  d Weather  Data  File  for  the  day  to  be 
forecasted.  System  calendar  data  is  used  to  identify 
known  holidays  in  order  to  substitute  the  appropriate 
load-weather  model.  The  resulting  hourly  forecast  for  the 
region  is  stored  by  date,  in  the  System  Load  Forecast  File 
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and  displayed  through  the  System  Load  Forecast  display. 


11.  State  Estimation 


The  State  Estimator  (STATEST)  estimates  the  Bus  Injection 
vector  making  use  of  the  various  real-time  measurements 
for  the  purpose  of  system  load  flow  and  real-time  con- 
tingency analysis.  It  also  makes  bad-data  checks  for  any 
possible  errors  in  instrumentation  or  communication. 

STATEST  is  typically  dimensioned  to  process  the  same 
network  used  by  the  On-Line  Load  Flow  programs,  and  is 
coordinated  in  design  with  that  package  so  it  may  be 
added  at  any  time.  This  package  is  capable  of  independent 
execution  due  to  the  inherent  stability  of  the  solution 
techniques  and  the  use  of  averaged  input  data. 

State  Estimation  is  superior  to  all  other  methods  for 
calculating  the  bus  injection  vector  of  the  internal  power 
system.  This  injection  vector  would  then  be  available  for 
running  a System  Load  Flow.  The  most  frequent  need  for  a 
System  Load  Flow  would  be  for  establishing  the  base  case 
for  Contingency  Analysis.  On  this  basis,,  State  Estimation 
would  be  executed  at  the  same  time  period  as  that  program. 
This  frequency  of  execution  would  be  satisfactory  for  the 
bad-data  identification  function. 

The  State  Estimator  module  will  use  the  following  types 
of  measurements: 

° Line  Flows , P and  Q 

0 Line  Currents 

0 Bus  Injections,  P and  Q 

0 Bus  Voltages 

P sue do-measurements  will  be  used  wherever  possible,  such 
as  zero  P and  zero  Q bus  injections  at  all  the  passive 
nodes  of  the  network. 

The  State  Estimation  methodology  is  based  on  the  full  use 
of  the  available  measurement  set.  The  algorithm  used  is 
the  method  of  measurement  transformation.  There  are 
currently  three  other  alternative  methods:  AEP,  basic 
weighted  least  squares  (WLS),  and  sequential  modified 
Kalman  filter.  The  AEP  method  uses  line  flows  only  and 
ignores  the  availability  of  other  measurements.  The  WLS 
and  the  sequential  method  both  use  the  full  measurement 
set,  but  are  based  on  a linearized  model  of  the  measurement 
set.  In  particular,  \i3ing  the  WLS  approach  entails 
recalculation  of  large  matrices. 


A-3T 


The  Transformation  method  applied  by  STATEST  transforms 
the  measured  quantities  into  variables  which  are  linearly 
related  to  the  system  state.  This  results  in  a constant 
gain  matrix  which  can  be  precalculated.  This  feature 
makes  the  Transformation  method  more  effective  for  on-line 
use  than  the  basic  WLS.  The  Kalman  filter  method  has  not 
yet  been  proven  to  work  efficiently  for  large  systems. 

The  method  used  by  the  State  Estimator  is  the  Transforma- 
tion method  introduced  by  Johns son.  Given  the  measurement 
set  Z,  a non-linear  transformation  g is  applied  such  that: 

Z’=g(Z,X) 

where  X is  the  state  vector. 

The  structional  transformation  g is  chosen  such  that  Z' 
is  linear  in  X.  Hence, 

Z ' =HX  + v 

where  H is  a constant  matrix  and  v is  Gaussian  zero-mean 
error.  The  standard  weighted  least  squares  approach  is 
applied  to  the  transformed  measurement  set  Z'. 

The  convergence  characteristics  and  accuracy  of  the  State 
Estimator  will  depend  to  a large  extent  on  the  accuracy 
of  the  network  model  that  is  supplied  by  the  user,  and  the 
measurement  system  meter  configuration  that  is  available. 
The  network  model  must  be  connected, and  complete  with 
valid  impedance  and  admittance  values.  For  example,  power 
industry  experience  has  indicated  that  the  reactive  power 
flow  estimates  are  very  sensitive  to  inaccuracies  in  line- 
charging susceptance.  Redundancy  in  measurements  will  tend 
to  reduce  the  estimation  errors  caused  by  inaccurate 
parameters,  but  this  will  be  strongly  dependent  upon  the 
number  and  location  of  the  measurements.  The  measurement 
configuration  should  be  based  on  the  reliability  and 
accuracy  of  the  measured  values  and  resulting  accuracy  of 
the  state  estimation. 

12 . System  Status  Processor 

The  System  Status  Processor  (SSP),  which  consists  of  three 
modules,  maintains  the  operational  in  or  out  of  service 
status  and  network  connectivity  of  the  following  power 
system  equipment  based  on  the  status  of  the  breakers  and 
disconnects  acquired  through  the  data  acquisition  soft- 
ware : 
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Nodes,  i.e.,  bus  bars  and  measured  load  buses 
° Lines 

0 Transformers 
° Generators 
° Capacitor  Banks 
0 Interchange  Tie  Lines 

The  resulting  information  is  used  to  update  the  logical 
and  mathematical  representation  of  the  power  system  for 
use  by  the  On-Line  Load  Flow  Program  and  by  the  man- 
machine  display  software. 

The  first  of  these  modules  compares  the  current  switching 
device  status  against  predefined  switching  device  con- 
figurations to  detect  equipment  status  changes.  In  this 
context,  switching  devices  means  breakers  or  disconnect 
switches,  while  the  term  equipment  is  used  to  indicate 
one  of  the  above  types  of  power  system  equipment.  In 
general,  the  status  of  equipment  is  determined  by  the  sta- 
tus of  several  switching  devices  within  the  station  con- 
figuration. This  predefined  switching  device  configuration 
is  established  in  tables  when  the  data  base  is  generated. 
For  instance,  a transformer  within  a station  may  be  out 
of  service  if  any  of  several  conditions  occur,  such  as  the 
tripping  of  several  breakers,  the  outage  of  all  lines 
feeding  the  station,  or  a combination  of  line  outage  and 
breaker  trips..  The  switching  device  configuration  is 
conveyed  to  the  software  in  terms  of  a cross-reference 
list, that  relates  all  possible  connections  of  equipment 
to  the  switching  devices. 

The  second  module  is  used  to  time  out  outages  and  returns- 
to-normal  for  equipment.  When  the  equipment  outages  are 
detected  by  the  first  module,  an  entry  is  made  in  a queue, 
where  it  remains  until  a prespecified  time  interval  is 
exceeded.  The  second  module  maintains  the  queue  and 
associated  tables  for  this  purpose. 

The  third  module  is  used  to  process  changes  to  line-orient- 
ed status  tables  to  reflect  current  operating  conditions. 
The  module  serves  as  a single  source  update  program  for 
the  system  line  and  transformer  status  tables.  Besides 
performing  status  change  requests  for  the  previous  module, 
the  third  module  processes  newly  alarmed  transformers  and 
transmission  line  overloads  and  line  overload  returns 
detected  by  the  data  acquisition  software. 
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13 . On-Line  Load  Flow  Program 


The  Load  Flow  Study  Program  provides  the  user  with  '.a 
comprehensive  capability  to  analyze  his  system's  behavior 
for  a variety  of  current  and  anticipated  operating  condi- 
tions. The  program  operates  on-line  using  the  console 
CRT's  for  efficient  interaction  between  the  dispatcher  and 
the  load  flow  model.  Complete  control  over  all  data  used 
in  the  analysis  is  established  through  a series  of  CRT 
data  displays.  The  analysis  may  be  initiated  by  a mult- 
iple number  of  operating  cases,  established  current  con- 
ditions, base  case  conditions,  or  previously  established 
operating  cases,  to  insure  fast  setup.  The  analysis  of  the 
load  flow  model  may  be  performed  using  the  Fast  Decoupled 
Load  Flow  Algorithm  to  provide  efficient  and  reliable 
on-line  execution.  Results  are  provided  in  summary  form 
through  CRT  displays  or  in  detail  from  using  printed 
reports . 

The  methodology  used  by  the  program  is  the  Fast  Decoupled 
Load  Flow.  This  is  a full  A-C  load  flow,  not  an  approx- 
imate one,  with  the  same  accuracy  as  the  well-known 
Newton-Raphson  method,  but  with  at  least  three  times  the 
computational  speed,  less  storage,  and  more  reliable 
convergence  characteristics.  Currently,  the  Fast  Decoupled 
Load  Flow  is  the  most  efficient  load  flow  method  avail- 
able and  is  the  most  suited  for  control  center  application 
where  speed  and  concern  for  storage  are  prime  consider- 
ations. 

The  Fast  Decoupled  Load  Flow  Algorithm  decouples  the 
real  power  and  reactive  power  equation  as  follows: 
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■where : 


AP  = the  mismatch  vector  (scheduled  net  real 
injection  - calculated  real  injection) 

AQ  = the  mismatch  vector  (scheduled  net  reactive 
injection  - calculated  reactive  injection) 

B'  = the  (-B) terms  of  Y-bus  matrix  (G  + jB)  omitting 
shunt  reactances  and  off-nominal  in-phase 
transformer  taps 

B"  = the  (-B)  terms  of  Y-bus  matrix  (G  + jB) 

omitting  the  angle  shifting  effects  of  phase 
shifters 

A0  = phase  angle  correction  to  be  solved  for 

AV  = voltage  magnitude  correction  to  be  solvdd  for 

The  constant  matrices  B'  and  B"  are  triangularized  only 
once, at  the  beginning  of  each  process. 

The  program  achieves  its  flexibility,  efficiency,  and 
interactive  capability  through  modularity  and  centralized 
data  organization.  The  program  consists  of  a supervisor, 
a set  of  optional  interim  study  processors,  a solution 
routine,  and  a results  processor.  These  processors 
establish  a unique  set  of  data  files  referred  to  as 
"Operator  Cases"  for  each  load  flow  study.  The  Operator 
Case  contains  all  data  associated  with  the  study  including 
raw  input  data  as  well  as  intermediate  results.  In  this 
regard,  the  Operating  Case  serves  the  same  functions  as 
a conventional  load  flow's  base  case.  A multiple  number 
of  Operating  Cases  are  supported  by  the  program. 

Program  control  is  established  by  the  Load  Flow  Study 
Supervisor  through  the  Load  Flow  Study  Control  display. 
This  display  allows  the  operator  to  initiate  a study  to 
either  current  operating  conditions  taken  from  real-time 
data  base,  a stored  base  case,  or  a previously  established 
operating  case  taken  from  the  load  flow  study  files 
stored  in  bulk  memory.  The  Supervisor  copies  the  appro- 
priately selected  data  into  the  initialization  data 
table  area  of  the  active  operating  case. 

Then,  at  the  discretion  of  the  operator,  the  Supervisor 
schedules  for  execution, one  or  more  of  the  interim  study 
processors  to  condition  data  for  use  in  the  load  flow 
study.  Each  of  these  processors  is  interactive, using 
functional  data  display  to  allow  the  operator  to  enter 
and  review  data  in  a format  familiar  to  him.  For  example, 
line  and  bus  data  are  entered  through  substation  level 
displays  similar  to  those  used  to  support  the  real-time 
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system.  Only  data  changes  required  for  a particular 
analysis  need  be  made.  These  processors  then  construct 
the  interim  study  results  tables  to  complete  the  data 
preparation  required  for  definition  of  the  system  model. 

The  assembled  data  is  then  analyzed  by  the  Load  Flow 
Solution  Routines  on  either  a primary  or  secondary 
computer  and  the  results  are  stored  in  the  currently 
active  Operating  Case.  Results  may  be  reviewed  through 
CRT  displays  in  summary  form  or  through  detailed  sub- 
station level  displays.  A separate  Load  Flow  Results 
Processor  is  provided  to  print  a detailed  report  of  the 
load  flow  study  results. 

One  remarkable  feature  of  the  Fast  Decoupled  Load  Flow 
Algorithm  is  that  it  can  be  used  for  both  full  AC,  and 
approximate  AC  Contingency  Analysis.  For  approximate 
solutions  the  algorithm  would  be  executed  with  just  one 
phase  angle  iteration.  A number  of  contingency  conditions 
could  be  checked  on  an  approximate  basis,  while  selected 
contingencies  could  be  solved  through  a full  AC  Load  Flow. 

lU . Other  Programs 

The  following  is  a listing  of  other  application  programs 
that  are  not  described  herein  but  which  may  be  of  interest 
to  the  borrower: 

0 Dynamic  Generation  Scheduling  Study 
° Real-Time  Contingency  Check  Monitor 
° Remedial  Action  Determination  Study 
° Radial  Load  Bus  Voltage  Control 
° On-Line  Loss  Matrix  Program 
° Off-Line  Power  Flow  Program 
° Interchange  Billing 
0 Energy  Accounting 
° Work  Order  Scheduling 
° Post  Disturbance  Analysis 
° Security  Analysis 
° Contingency  Remedial  Action 
° Bus  Load  Forecasting 
° Unit  Commitment 
° Power  Flow 
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APPENDIX  B 


GLOSSARY 


' 


GLOSSARY 


ACE 

ADC 

AGC 


ASCII 

Auxiliary  Memory  or 
AUX  MEM 

Bulk  Delivery  Line 

ISE 

Bulk  Delivery  Substa- 
tion 

CONTROL 

CPU 

CRT 


Cursor 


Area  Control  Error  - The  area  net  interchange 
minus  the  biased  scheduled  area  net  interchange. 

This  signal  is  used  by  the  AGC  programs  to  meet 
the  G&T's  regulating  responsibility. 

Analog-to-Digital  Converter  - A device  that  con- 
verts a signal  that  is  a continuous  function  of 
a variable, into  a representative  number  sequence. 

Automatic  Generation  Control  - The  regulation  of 
the  power  output  of  electric  generators  within 
a prescribed  area  in  response  to  changes  in  system 
frequency,  tie  line  loading^  or  the  relation  of 
these  to  each  other,  so  as  to  maintain  the  sched- 
uled system  frequency  and/or  the  established  inter- 
change with  other  areas  within  predetermined  limits. 

USA  Standard  Code  for  Information  Interchange. 

A rapid  access  device  used  for  the  on-line  storage 
of  logic  and  data. 

A small  delivery  point  with  a single  controllable 
breaker  or  motor-operated  switch. 

A delivery  point  with  dual  feeds,  transformation 
and  multiple  outputs.  Contains  several  control- 
lable devices  including  breakers,  switches,  and 
load  tap  changers. 

Controller  - The  electronic  interface  between  the 
CPU's  IOP  and  a peripheral  device. 

Central  Processing  Unit  - The  unit  of  a computing 
system  that  includes  the  circuits  controlling  the 
interpretation  and  execution  of  the  instructions. 

Cathode  Ray  Tube  - An  electron  beam  tube  in  which 
the  beam  can  be  focused  to  a small  cross  section 
on  a luminescent  screen  and  varied  in  position 
and  intensity  to  produce  a visible  pattern.  The 
primary  man/machine  interface  device  in  the  system. 

A special  CRT  character  used  for  marking  specific 
positions  on  the  face  of  the  tube,  thereby  allowing 
the  System  Dispatcher  to  communicate  selection 
of  a particular  CRT  representation  for  BPU  action. 
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Delivery  Point 

Any  point  in  the  power  system  of  which  power 
is  received  and  metered  from  the  interconnected 
utilities.  Can  be  any  of  three  configurations. 
Meter  Point,  Bulk  Delivery  Line  Tap,  or  Bulk 
Delivery  Substation. 

DS 

Data  Set  - A device  used  to  interface  the  control 
system  to  the  communications  channels,  by 
modulating-demodulating  digital  signals  into 
audio  tone. 

DSC 

Data  Set  Controller  - A device  connected  to  the 
IOP  that  controls  the  operation  of  the  data  set. 

DS/C 

Data  Set/Control ler  - The  combination  of  a data 
set  and  its  associated  data  set  controller. 

ECS 

Energy  Control  System. 

EDC 

Economic  Dispatch  Calculation  - The  distribution 
of  total  generation  requirements  among  alternate 
sources,  to  optimize  system  economy  with  due 
consideration  of  both  incremental  generating 
costs  and  incremental  transmission  losses. 

Function  Panel 

A grouping  of  pushbuttons  used  to  communicate 
specific  System  Dispatcher  commands  to  the  CPU. 

Hardware 

The  mechanical,  magnetic,  electrical  and  elec- 
tronic devices  incorporated  into  the  system. 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

I/O 

Input/Output  - Pertaining  to  all  hardware  and 
activity  that  transfers  information  into  or 
out  of  a computer. 

Keyboard 

A device  used  in  conjunction  with  the  CRT  for 
alphanumeric  data  entry. 

KSR 

Keyboard-Send-Receive  Unit  - A typewriter-like 
device  used  by  the  programmer  to  communicate 
with  the  software  operating  system. 

Load  Flow 

A calculation  that  provides  power  flows  and 
voltages  for  a specified  power  system, subject 
to  the  regulating  capability  of  generators, 
condensers,  and  tap-changing-under-load  trans- 
formers, as  well  as  specified  net  interchange 
between  individual  operating  systems. 
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Logger 

LTC 

Meter  Point 

NAPSIC 

Off-Line 

On-Line 

Participation  Factor 
Penalty  Factor 
Poll 

Printer 

Quality  Coding 
Real-Time 


A medium  speed  printing  device  used  to  record 
alarms,  logs  and  other  pertinent  operating 
information . 

Load  Tap  Changer . 

A small  delivery  point  with  no  controllable 
breakers  or  switches. 

North  American  Power  System  Interconnection 
Committee . 

Pertaining  to  equipment,  devices  and  programs 
not  under  direct  control  of  and  interacting 
with  the  real-time  control  system. 

Pertaining  to  equipment,  devices  and  programs 
under  direct  control  of  and  interacting  with 
the  real-time  control  system. 

A factor  which  is  used  to  allocate  generation 
changes  to  a unit.  Separate  factors  are  pro- 
vided to  allocate  short  term  (regulation)  and 
longer  term  (economic)  changes  in  generation. 

A factor  which,  when  multiplied  by  the  incre- 
mental cost  of  power  at  a particular  source, 
produces  the  incremental  cost  of  delivered 
power  from  that  source. 

To  send  a command  to  a piece  of  hardware 
requesting  that  specified  stored  data  be  trans- 
mitted, processing  the  received  data  point-by- 
point in  logical  sequence,  and  storing  the 
data  for  future  use. 

A high  speed  hard  copy  device  used  to  document 
programs  and  lengthy  reports  of  operating 
information . 

A label  or  other  designation  indicating  the 
source  and/or  reliability  of  data. 

Pertaining  to  the  performance  of  a computation, 
during  the  actual  time  that  the  related  physical 
process  transpired, in  order  that  the  results  of 
the  computation  can  be  used  in  guiding  the 
physical  process. 
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RTU 

- Remote  Terminal  Unit  - That  part  of  the  system 
that  includes  all  supervisory  control  relays 
and  associated  devices  located  at  the  remote 
station  for  selection,  control,  indication, 
telemetering  and  other  functions  to  be  performed 

SCADA 

Supervisory  Control  and  Data  Acquisition. 

Scan 

- To  send  a command  to  a piece  of  hardware  re- 
questing that  specified  sensors  be  connected 
to  measuring  equipment  and  a digital  count 
value, or  a binary  digit, be  generated  and  trans- 
mitted, processing  the  received  data  point-by- 
point in  logical  sequence,  and  storing  the 
generated  data  for  future  use. 

Software 

Programs  or  routines  which  instruct  the  opera- 
tions of  a computer (s)  and  the  supporting 
documentation  which  describes  them. 

System  Dispatcher 

The  person  or  persons  duly  authorized  to 
operate  digital  monitoring  or  dispatch  equipment 

UPS 

Uninterruptible  Power  Supply  - Equipment  used 
to  supply  power  to  critical  loads  even  when 
the  normal  power  supply  fails. 
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PRICING  WORK  SHEETS 


Name  of  Bidder 


1.  Total  System  Firm  Price 

Including  all  hardware,  software, 
installation,  integration,  test, 
test  equipment,  documentation, 
warranty,  insurance  and  oppor- 
tunances.  Taxes  not  to  be 
included . 

2.  Insurance  Provisions 

Has  your  bid  taken  into  account 
the  insurance  provisions  of 
Section  9,  Article  IV,  Section  3. 
(Answer  yes  or  no) 

3.  Conformity  with  Bid  Documents 

Bidder  hereby  certifies  that  he 
agrees  to  all  provisions  of  the 
specification  and  bid  documents, 
unless  exceptions  are  specifically 
and  clearly  listed  in  the  proposal 
and  identified  as  Exceptions. 

Bidders  printed  terms  and  conditions 
are  not  considered  specific  excep- 
tions. Any  exceptions  which  Bidder 
has  taken  are  listed  on: 

4.  Major  Subsystem  Price  Details 

The  Bidder  shall  submit  subsystem 
pricing  as  set  forth  below: 

4.1  Total  price  of  computer  system 
and  peripherals 

4.2  Total  price  of  communication 
subsystem  including  computer 
interface  hardware 


Page (s) 


$ 


$ 
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A. 3 Total  price  of  consoles  including 

CRT’s,  display  generators  and  com- 
puter interfaces  $ 

4.4  Total  price  of  wallboard  assembly 

less  internally  mounted  components  $ 

4.5  Total  price  of  RTU's  $ 

4.6  Total  price  of  local  RTU  or 

equivalent  device  $ 

4.7  Total  price  of  analog  ACE 

calculator  $ 

4.8  Total  price  of  video  hardcopy 
printer  including  necessary 


interfaces  $ 

4.9  Price  of  RTU  test  sets  (total)  $ 

4.10  Price  of  all  other  hardware  $ 

4.11  Total  hardware  price  $ 

4.12  Price  of  all  application  programs  $ 

4.13  Price  of  the  operating  system(s)  $ 

4.14  Price  of  all  programmer's  aids  $ 

4.15  Price  of  all  utility  software  $ 

4.16  Price  of  all  system  software 


(communications,  special  handlers, 
man-machine,  etc.)  $ 

4.17  Price  of  software  other  than  above  $ 

4.18  Total  software  price  $ 

5.  Engineering,  Installation  and  Manage- 
ment Prices 

5.1  Total  man-hours  and  price  including 
expenses  allocated  for  all  field 

and  factory  support  activities  — 

subsequent  to  factory  shipping  $ 

5.2  Program  management  and  system 

engineering  $ 
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6.  Miscellaneous  Prices 


6.1  Documentation  $ 

6.2  Shipping  $ 

6.3  Insurance  $ 

6.4  Initial  delivered  expendables  $ 

6.5  Warranty  $ 

6.6  Contractor's  bond  $ 

7.  All  other  costs  not  included  in 
Items  4 through  6.  The  sum  of 
Items  4 through  7 should  equal  the 

value  entered  in  Item  1 $ 

8.  Optional  Item  Prices 

8.1  Firm  price  for  initial  spare 

parts  $ 

8.2  Training  program  $ 

8.3  One-line  diagrams  and 

associated  tabular  displays  $ 

8.4  Supplier  provided  maintenance 

plan  $ 

8.5  (a) Security  monitoring  imple- 
mentation if  provided  with 
initial  system.  (Include 

hardware  and  software)  (b)Same  $ 

as  Item  (a)  but  provided  after 
system  acceptance  $ 

8.6  Dual  Port  Interface  $ 

8.7  Sequence  of  events  capability 

per  applicable  RTU's  only  $ 

9.  Post  Acceptance  Support 

Provide  daily  rate  costs  including 
per  diem  for: 

9.1  System  analysts  $ 
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9.2  Other  software  personnel 


« 


$ 

9.3  System  hardware  maintenance 

personnel  $ 

10.  Incremental  Prices 

The  Bidder  is  requested  to  provide 
incremental  prices  for  the  following: 

10.1  Average  RTU  prices 

a)  Small  $ 

b)  Medium  $ 

c)  Large  $ 

10.2  RTU  Points 

a)  Discrete  inputs  with 

memory  in  groups  of : $ 

b)  Discrete  input  w/o  memory 

in  groups  of : $ 

c)  Analog  points  in  groups  of:  $ ^ 

d)  kWh  accumulator  points  in 

groups  of:  $ 

e)  Analog  set  points  in  groups 

of : $ 

f)  Pulse  drivers  in  groups  of:  $ 

10.3  Additional  CPU  Memory 

a)  Increment  (k  words)  

b)  First  additional  increment  $ 

c)  Subsequent  increments  $ 
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10.4  Disk 


Additional  disk  packs  for 
(k  bytes) 


a) 


$ 


b)  Additional  disk  drives 
including  controller  if 
required  $ 

10.5  Console  shell  price  per  bay  $ 

10.6  Selected  applications 


a) 

AGC/ED 

$ 

b) 

Interchange  transaction 
scheduling 

$ 

c) 

Load  forecasting 

$ 

d) 

Unit  commitment 

$ 

e) 

Interchange  transaction 
evaluation 

$ 

f) 

Production  costing 

$ 

g) 

After-the-fact  interchange 
billing 

$ 

D-5 


■ 


APPENDIX  E 


REFERENCES 


1.  M.S.  Blynn,  J.N.  Boucher,  "The  Computer  Subsystem," 

Leeds  and  Northrup  Company,  North  Wales,  Pennsylvania,  1977- 

2.  J.F.  Dopazo,  "Power  System  Security,"  American  Electric 
Power  Service  Corporation,  New  York,  New  York,  1977. 

3.  T.E.  Dy  Liacco,  "An  Overview  of  Power  Control  Centers," 

The  Cleveland  Electric  Illuminating  Company,  Cleveland, 

Ohio,  1977. 

h.  D.G.  Franz,  "Energy  Control  Center  Data  Acquisition  and 

Communications  Subsystem,"  TRW  Controls,  Houston,  Texas,  1977. 

5.  T.P.  Kenealy,  "Man/Machine  Interface  Subsystem,"  Control 
Data  Corporation,  Minneapolis,  Minnesota,  1977. 

6.  R.  Podmore , N.M.  Peterson,  K.N.  Stanton,  "Economic  Dispatch 
and  Scheduling,"  Systems  Control  Incorporated,  Palo  Alto, 
California,  1977- 

7.  "Energy  Control  System  Planning  Report,"  MACRO  Corporation, 
Fort  Washington,  Pennsylvania,  1977. 


U S GOVERNMENT  PRINTING  OFFICE  : 1979  620-036/5064 


In  December  1975,  Congress  passed  the  "Metric  Conversion  Act  of  1975." 
This  Act  declares  it  to  be  the  policy  of  the  United  States  to  plan  and 
coordinate  the  use  of  the  metric  system. 


The  metric  system,  designated  as  the  International  System  of  Units 
(SI),  is  presently  used  by  most  countries  of  the  world.  The  system  is 
a modern  version  of  the  meter,  kilogram,  second,  ampere  (MKSA)  system 
which  has  been  in  use  for  years  in  various  parts  of  the  world. 


To  promote  greater  familiarization  of  the  metric  system  in  anticipa- 
tion of  the  U.S.  converting  to  the  system,  REA  is  including  metric 
units  in  its  publications.  This  bulletin  has,  therefore,  been  prepared 
with  the  International  System  of  Units  (SI)  obtained  from  ANSI  Z 
210-1976  - Metric  Practice.  Approximately  equivalent  Customary  Units 
are  also  included  to  permit  ease  in  reading  and  usage,  and  to  provide 
a comparison  between  the  two  systems. 


